Moving to PostgreSQL #358
scionaltera
announced in
Blog
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I spent the past few days ripping out the DynamoDB module and replacing it with JPA and PostgreSQL. I really liked using DynamoDB because it's a lot more flexible when things change, and I use it a ton at work so it's familiar. SQL databases are much more rigid and I don't look forward to needing things like Flyway or Liquibase in the future. It's not so bad right now when the build actively deletes the database each time you run it, but sooner or later it's going to become important that the database stays there when you restart the game, and DynamoDB would have been much easier to deal with after that happened. Ultimately it was a conversation with someone on Discord that changed my mind about the technology stack.
At work we're all in on AWS. Everything is in there, so I'm very familiar and comfortable with building things in there. I've even built an entire MUD codebase using Lambda, API Gateway, Cognito, ActiveMQ, DynamoDB and SQS. No servers at all. It was pretty cool that it worked, but the Lambda cold starts were a killer. That's not really a topic for here, though. When I was first thinking about technology choices for Agony Forge it seemed natural to use DynamoDB, Cognito, ActiveMQ, and run Docker containers in ECS or EKS. I was thinking about scaling, clustering, zero downtime deploys, and all that kind of enterprise stuff we do at work. And all that stuff is great and can be a lot of fun to work on, but it's complicated and expensive. As I get closer to having something to deploy, I started thinking about things from more of a hobbyist's perspective.
It turns out that for a small hobby project, scale isn't that important. Clustering isn't either. Zero downtime deploys? Nope. Chances are I'm never going to have so many players that one instance can't support them all, and probably neither are you. Chances are that I'm never going to be in a situation where having the MUD down for a minute or two while it reboots is intolerable. And, chances are nobody's going to think having their hobby project vendor locked to AWS is a good thing.
So, the first to go was Cognito. Spring Boot already has built in support for OAuth2, and Cognito was actually pretty difficult even for me to set up correctly. I switched over to Spring Security login with GitHub, and will likely change it to Google later on since I think more people have Google than have GitHub. Changing that removed one major dependency on AWS.
I switched from ActiveMQ to RabbitMQ for AWS reasons as well. I don't know why, but ActiveMQ support on AWS was lagging pretty far behind and I could no longer find a working Docker image for the old version AWS supported. Their RabbitMQ version is much more up to date and there are Docker images available for the exact version. It was an easy change to make, with no functional change to the MUD, and so well worth doing. You can easily run RabbitMQ in a container anywhere with basically zero configuration, so I'm keeping it. More on that later.
Now, I'm switching from DynamoDB to PostgreSQL. That will break the final tie to AWS and should enable people to run this anywhere they want. I'm thinking about trying to run it on the NAS at my house, and that's really why I wanted to write this article in the first place. This project is unlikely to make any money, ever. I don't plan on charging for it or selling it or anything like that. I'll be thrilled if anyone actually wants to play it once it's playable. Given that, the idea of spending a hundred bucks a month to run it was a little unpalatable, and I expect it would have been for anyone else looking at the project as well. The idea of running it for free on hardware I already have? That sounds really nice!
Going forward I am committing to building this in a way that does not require any AWS services, although if you are good at AWS and want to, you can absolutely run PostgreSQL in RDS, RabbitMQ in AmazonMQ and the MUD itself in EKS. There is nothing preventing that and it would work really well. If you want to run it on Azure, or even the machine in your garage, you should be able to do that too.
Beta Was this translation helpful? Give feedback.
All reactions