You don't need a database, a queue, a distributed system: Go is enough
simonedutto.github.io
You don't need a database, a queue, a distributed system: Go is enough
1–10 of 37 posts
Re: You don't need a database, a queue, a distributed system: Go is enough
#2This article is a reminder to me and you all that you probably don’t need to make things harder for yourself.
Re: You don't need a database, a queue, a distributed system: Go is enough
#3Sounds like it’s actually “SQLite is enough.” With which I’d agree.
Re: You don't need a database, a queue, a distributed system: Go is enough
#4If you are working on this specific silly use case. What is the point of this article?
Re: You don't need a database, a queue, a distributed system: Go is enough
#5If you are working on this specific silly use case. What is the point of this article?
I agree it's silly, but sometimes ideas or POCs are silly but worth shipping.
Don't you agree?
Re: You don't need a database, a queue, a distributed system: Go is enough
#6I 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
Re: You don't need a database, a queue, a distributed system: Go is enough
#7I 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
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
Re: You don't need a database, a queue, a distributed system: Go is enough
#8I am a fan of "distributed computing" - but I do not make it complicated.
I have created a generic broker daemon, which reads messages (in) and places them in the appropriate service (queue) which, at this time, is using sqlite.
Then, a bunch of daemons (workers) connect to the broker service, and processes anything in the queue (process) and tells the broker when the message is OK or errored (output)
I also have commands to check a service queue, active workers, etc.
The broker is generic, simple, and fast. The workers do the actual, specific job.
The communication between the clientbroker and brokerworker is ZeroMQ. There is also a "publish" if you choose to join, which some client programs do.. so they can see any errors on-the-fly.
Installation/deployment is on a linux server using SystemD. Nothing fancy or complicated.
Purpose is that this broker could serve useful for many projects I do in the future.
Re: You don't need a database, a queue, a distributed system: Go is enough
#9Title: You don't need a database.
Half way down the article: The questions are stored in a sqlite database
Re: You don't need a database, a queue, a distributed system: Go is enough
#10It's a bit click-bait-ish. You don't need computers, here is my tic-tac-toe on a piece of paper + pen. Just use the right tool for the job.