Refactor camouflage data structure

[carlssonemil]

As discussed in #34 ideally we should refactor the data structure of the camouflages (and preferably the weapons too) by adding unique IDs to completely circumvent the possible name-change (or misspell) issues that might arise down the line.

Preferably this new structure would have some sort of logic to handle IDs automatically so we won't have to manually keep track when adding new camouflages, or weapons.

Maybe even going as far as adding a completely separate Postgres database instance to handle all data-storage (except progress) for us, with an API that fetches all available data upon page load? Adding a database will make it harder to contribute changes though 🤔

Putting this in the backlog for now for future reference.

[sol3uk]

To be fair, hosting a DB is taking everything to the next level and incurs additional complexity (storing and deploying secrets, managing DB uptime and query speed), cost and legality (storing user data, keeping it "anonymous", GDPR etc) which I've always tried to avoid with side projects and never actually got around it doing in most cases. And because most recently heroku have stepped down from offering DB hosting, it's clear that the market for free DB hosting is getting less, soon we might not have much choice for free DB hosting at all.

So since this app will only have a fixed number of camouflages in it's lifetime, I would suggest keeping with the fixed file storage you already have.

In terms of ID's, we wouldn't really need to auto-gen them on every add (how often would that really be anyway? maybe 1-2 new weapons per quarter, maximum?), we can generate them in bulk and attach them to the data models manually. In the past I have used an ID system like nanoId to generate really small (5-6 character long), user friendly IDs that aren't a hassle and still have a miniscule chance of duplication.

[sol3uk]

If a worry is contribution and making it easy, I know it sounds stupid but something as simple as google sheets is actually an option. Probably the simplest solution next to a normal document store. I wouldn't use an SQL DB for this really, there's not enough complexity in the entity relationships to justify it.

[carlssonemil]

We would only host the default data, not the user's progress. It sucks that Heroku has turned off their free-tier but there are still free alternatives. But yes, I agree with you completely. We should probably be fine just having simple numerical IDs as well, but nanoid is a good alternative!

[sol3uk]

Yeah I assumed the default would be fine by itself, but didn't want to assume that would be all you would want to do!

I had ideas previously for other apps of wanting to be able to store user progress anonymously as a shared "magic link" style system, where a user would have a store ID assigned to them when they began saving progress, then that would be parsed into maybe their unique progress "link" in another URI which would be a super simple document store which could be accessed by any client with the ID and sync up/share progress. It wouldn't inherently link any user data to any person (avoiding legality and complexity for things like user profiles), but would still give people a way to share progress between clients (i.e. web, tablet, mobile, or even between users)