Casino sim
A final class project built as three services that had to talk to each other: an Express game engine, a Django REST user system, and a React front end. Play money, real distributed-systems problems. 2023.
- Three separate services rather than one app — the split was the actual assignment.
- Express for the game system, Django REST Framework for user management, React on the front.
- Casino-style games with play money, which is a convenient excuse for state that has to be exactly right.
- Localised into English and Polish, for a class project that was only ever demoed once.
- First time I used rspack, which I later took to a client project.
outcome — A class project, graded and demoed once — to a room of Polish speakers who didn't need the Polish translation. Never touched again after that.
- React
- RSPack
- ExpressJS
- DjangoRestFramework
- TailwindCSS
The final project for a class, and the brief was architectural rather than product: build something out of services that have to communicate, not one application that does everything.
So it's a casino sim. Play money, no payments, nothing at stake — but the games gave me the thing I actually needed, which is state that has to be exactly right and that two services both care about.
three services, one balance#
Express ran the game system. Django REST Framework handled user management. The React front end talked to both.
Splitting it that way turns a simple thing into an interesting one immediately. A round finishes in the game service and a balance changes in the user service, and those are two different systems that can each fail on their own. What happens if the game resolves and the balance update doesn't? What does the front end show while it's mid-flight?
Those are the questions the assignment was actually asking, and you don't encounter them at all if you build it as one app with one database. Getting them slightly wrong on a project where the money is fake is a very cheap way to learn them.
picking the boundaries#
The split I chose was along the lines that had genuinely different shapes: game logic is stateful, fast and fiddly; user management is CRUD with auth attached. Two different problems, so two different services, in two languages that each suit their half.
That's the part I'd defend now. The part I'd do differently is that I drew the boundaries once, at the start, and then lived with them — where the real skill is noticing when a boundary is wrong and moving it.
the translations nobody asked for#
It's localised into English and Polish. It's a class project. It was demoed once, to people who all speak Polish.
I did the same thing again the year after on the ShareX image host, which went to four languages for a user base of one, so this is apparently a habit rather than an incident. Both times the appeal was the same: i18n is a self-contained problem with a visible finish line, and doing it feels like progress in a way that the actual hard part — here, what happens when the game service and the user service disagree — does not.
It's the tidy work you do to avoid the untidy work, and it produces commits, which is what makes it so hard to notice.
the rspack thread starts here#
This is where I first used rspack, on a project where being wrong cost me nothing. That's the whole reason I was willing to push for it later on the art gallery, which was client work and a much more expensive place to experiment.
Trying new tools on the projects that don't matter is how you get to use them on the ones that do.