Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate better hosting options #12

Open
oxguy3 opened this issue Nov 16, 2017 · 9 comments
Open

Investigate better hosting options #12

oxguy3 opened this issue Nov 16, 2017 · 9 comments

Comments

@oxguy3
Copy link
Owner

oxguy3 commented Nov 16, 2017

Right now, the flags.ox3.in domain just points to the GitHub Pages version of this repository. This gets the job done well enough, but it's not ideal -- GitHub isn't a CDN, and also comes with limitations such as no HTTPS for my custom domain name. Perhaps someone like MaxCDN would be willing to host this for free? Or else I could investigate hosting it myself on something like S3 (I don't think this repository is popular enough to empty my wallet).

@oxguy3
Copy link
Owner Author

oxguy3 commented Nov 16, 2017

Just did some calculations -- even before any SVG optimization, the average country/subdivision SVG is 68.8912 KB (calculated with this gawk command). If I served 1,000,000 SVG flags every month, that would be 68.8912 GB of bandwidth, which would only be a $5.25 monthly bill on S3 (according to the AWS calculator). That's entirely reasonable, especially since I expect the monthly volume to be far far less than a million -- I'll bet my actual bill stays under 50 cents (if this repository got popular enough to be expensive, I could ask for donations and probably find a few people willing to toss me a buck).

So I'm gonna go ahead and get this new hosting set up. It's also gonna be on a new domain and I think I'm gonna make the URL scheme a little bit better (I'd like flags to also be accessible by their alpha3/numeric/FIFA codes, and I'd like the potential to expand to serving other images/data than just flags in the future). And don't worry, I'll keep flags.ox3.in alive for the foreseeable future with no changes to URL scheme, since people are already relying on it.

@RudeySH
Copy link
Contributor

RudeySH commented Nov 16, 2017

I should note that I plan on downloading this repo and hosting the flags in the same directory where my web apps are so they can use them without depending on a third party service. I would assume some (if not most) other users do the same.

@oxguy3
Copy link
Owner Author

oxguy3 commented Nov 16, 2017

Yep, and I definitely want to continue to support that use case as well. I just want to make sure there's always the option to use these flags without needing your own hosting (the original reason I put this together, after all, was for use with Google Sheets).

@oxguy3
Copy link
Owner Author

oxguy3 commented Nov 16, 2017

@rlenders I figured I should let you know since you have a fork -- I'm making some pretty radical changes, and I probably won't be able to merge any PRs you make from now until I'm done. I'm moving from gh-pages to a new master branch as the main branch (the gh-pages branch is just gonna remain untouched as legacy support for anyone using the flags.ox3.in domain) and I'm gonna be restructuring everything. The octicons repository is another NPM-based project for distributing SVG files that seems to be structured pretty intelligently, so I'm using it as a model. Bear with me for a day or two -- this is my first time really delving into NPM. 😛

@RudeySH
Copy link
Contributor

RudeySH commented Nov 16, 2017

Sure. If I can make any suggestions, here are some ideas I had about a better setup:

  • Start collecting Wikipedia links instead of SVG files, to allow for easier updating of flags;
  • Create a script that downloads the SVGs from these Wikipedia links, these files get included in the repo;
  • Have SVGO automatically do it's magic after downloading the SVGs;
  • If you want to keep the PNGs, create a script that rasterizes the SVG images.

@oxguy3
Copy link
Owner Author

oxguy3 commented Nov 16, 2017

Ooh hadn't thought about storing Wikipedia links, good idea. I'm not sure I want pulling updates from Wikipedia to be entirely automatic, but I'd at least want to be monitoring those links for changes. I'm also looking to figure out a way to be notified of updates to the ISO standard (without paying ISO an arm and a leg) since it changes occasionally.

But yeah, otherwise, you basically summed up the process I was planning. I'm also planning to support using other code systems than ISO 3166-1 alpha-2 (i.e. ISO 3166-1 alpha-3 and numeric, FIFA, IOC, etc...). The build process will be pretty flexible -- you'll be able to specify if you want SVGs (optimized) and/or PNGs, and you'll be able to specify what code system(s) should be used for the file names.

@RudeySH
Copy link
Contributor

RudeySH commented Nov 16, 2017

Sounds great! I have one more thing to add, have you considered using UNLOCODE for city flags?

@oxguy3
Copy link
Owner Author

oxguy3 commented Nov 16, 2017

Ahhh, thank you! I knew there had to be an international standard for cities! I had been planning on using FIPS codes for cities and just being forced to say "sorry, rest of the world" (FIPS is US-only, at least for city/county level), but this is a much better solution (although I'll probably also support FIPS codes because that's what everyone uses in the U.S.).

@oxguy3
Copy link
Owner Author

oxguy3 commented Nov 17, 2017

FYI, I've been writing up a lot of notes on how I'm gonna implement this; if you're curious, they're here: miscnotes.md (commit d160147)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants