Have a backend

[glacials]

We're currently hosted on GitHub Pages, so there's no possibility for backend code. We'll probably eventually want to move, because the advantages are growing with time. This is a list of them.

• We can supply API endpoints like "get current sets in Standard" rather than requiring clients to filter sets by enter/exit date
• Having multiple endpoints that return the same type of data (e.g. get current sets and get all sets) would become easier if sets were actually backed by a database, not stored as raw JSON
• We can more easily supply fields in the API response like set icons, which are strictly generated from other fields like set code, more easily (although this could also be accomplished with some local code to generate these parts of the JSON).

[inuyasha82]

Definitely agree.
Obviosuly there are several options, and everyone has its pro/cons.
I think that we need first:

• Choose a programming language for backend (php, java, javascript, go, etc)
• Design a minimum set of endpoints
• Identify a suitable hosting service.

I don't know if it could be useful, but few months ago i started to work on a small restservice for mtg (to return information about a single set/all sets in xml and json format (just as an exercise to learn golang)
(https://github.com/inuyasha82/mtgrestservice), an idea could be to reuse that code (in that case we just need to add the code to parse different files), so 50% or more of the code is already done, and we can start to offer a broaden service.

This approach has some cons:

• Find a golang hosting (i don't know if there are some free golang hosting services)
• We still have to manually updates the sets (i have to do it for the xml in that service)

Anyway from my perspective i worked/i'm working with java and javascript (server and client side) and in the past i worked a little with php, so i can definetely help with the backend part.

I think that this issue should be an initial design discussion on what the api backend will be. And what kind of services we want to offer. I.e.:

1. We want to continue offering only information about what is in standard, or broaden the type of information available? (as pointed in API v5 #52 or maybe more?)
2. We want to add the translation service as pointed in Translate content #39? (i have to check, but maybe this can be done client side even now, with some translation libraries, i did tit in angular, but i don't know if it can be done easily with vue)

[glacials]

We are now off GitHub Pages! Thanks to inspiration from #78 I've moved us to Google Cloud Storage (equivalent to AWS S3). There's a cloudbuild.yaml file in the root now that "builds" the site, which includes generating the API from an api/internal.json file. We can use this file like a database, over-including sets in it and letting the build step filter them down when generating the real API.

This is a bit more restrictive than having an actual backend, but I think the shoe fits considering our content stays more or less the same for three months at a time. The $$$ costs will be negligible compared to a full backend, and we get what we need. Next step will be to add a cron to re-generate the API once an hour or so, which will let us provide an actual sets-currently-in-Standard API.