21–30 of 37 posts
That said, Scalability? But at what COST? [http://www.frankmcsherry.org/assets/COST.pdf] was a good note that orienting around scaleable technologies can be very inefficient- scalable does not mean either fast or economical.
...Wait, ten years ago the advice was that this should be one of your last decisions: your application should be able to work with minimal changes with any DBMS, and tying yourself to a specific vendor from the start was considered a bad idea. Did it change while I was not looking?
I also try to move centralized computing to decentralized computing more and more. And that can also be done to let the client do more computing. And also storage, is it needed to store in central, or can the user store it.
Many times people thinking that we should have a central system, with all the truth. But let it be a part of the users.
It makes also the central part simple, and because the central part is simple, it is easier to scale.
The entire set fits happily in memory and takes milliseconds to respond.
Earlier quoted context omitted.
You are right, but i can roll updates during the night without causing any issue. Since after you finished playing you don't have a way to access your old games anymore
That works for the specific case presented here. As soon as you have users from other timezones, ”during the night“ becomes a really complicated concept quickly.
You can get pretty far with simple in memory solutions when your problem space fits entirely within the constraints. We have a Go microservice for linking accounts to their proper federated logins with some associated metadata. There’s a refresh process that runs every fifteen minutes. The entire set fits happily in memory and takes milliseconds to respond.
If the data in your app doesn't matter at all, and you have no availability requirement, sure keep everything in memory. I don't see what Go has to do with it however, any language should be fine.
(Rust gods please dont see this)
I wanted to learn some Go and I thought "I will just reimplement my music library with it". So basically the task was to write a backend API that maintains a database of music files with associated ID3 tags, and so on.
The original backend is Python over SQLite, which works fine enough.
As I started to reimplement the functionalities, I though "why should I use a database anyway ?" and started just pushing the ID3 tags a list of structs. It turns out that having an in-memory list of structs for 50k music files is not a problem at all for a raspberry pie. It's not that musch memory and it's fast enough to create so that I don't have to persist it and it's fast enough to scan for a search.
In the end, I may use SQLite anyway because FTS5 is just so good, but yes... sometimes you don't need a database.
I don’t disagree with the premise for very small applications, but > The quiz state machine is full in memory > The queue system for the matchmaking is in memory Means those will be nuked as soon as a new version gets uploaded. it really wouldn’t have been much extra work to put this into SQLite as well, and would lead to a much better user experience during updates