Use a database

[DavidBenko]

Per the comment here, this will never scale if you want to search a large amount of logos. Host the logos on some service like s3 & use a database to store the logo metadata.

This also fixes the issue of you having to modify your codebase to add content. Code & content should be separate. Not to mention the name conflicts & duplicates. If each record has a serial number or guid, you won't have conflicts like that.

[saiichihashimoto]

As we and this guy addressed, the file size won't be an issue, even at much larger scale. Also, we wanted this github repo to exist so others can simply include the whole of the logo directory into their projects.

However, we do have a few issues we'd like to address at scale:

• Get on a CDN
  • MaxCDN recently reached out to us and we're using them now! A lot of the loading times should be much quicker now.
• Stop generating pngs on the fly.
  • Being on a CDN helps with this problem quite a bit, but still doesn't address the issue. We're also caching them in a redis database, so there's a few layers before having to regenerate a png, but it would definitely be better to store them somewhere. Maybe we'll auto generate them into this repo, it won't actually take up much space (yet).
• Split the logos into their own JS file rather than embed them into the page.
  • This is similar to your db comment and was suggested by that guy (/u/putin_vor). Currently, most assets and files are cached in your browser as long as possible and, when they change, we append a new query parameter to the file so your browser reloads them. The main page is only cached for a day, however because we have the logos "db" embedded in there. If we split that into a separate JS file, we can treat it like another file and be good.

Anyways, I'm going to keep this issue until we a) address these issues or b) split them into separate issues and close this one up. Thanks @DavidBenko for your suggestions!