Choosing stack for a multiplayer game in 2020


There is a moment of bliss when you start a new project and a whole world of possibilities lies in front of you. This feeling can be overwhelming, but with a bit of discipline, you can make a quick progress.

At this phase of the project quick iterations is what you want to spend your time on. Dwelling too long on what technology stack to choose probably won't do you any good.

Don't worry about the risk of making a mistake. If you choose mature and widely used tooling, there is little chance that your project will be special enough to outgrow its capabilities.

Let's look at the basic requirements and technologies needed to complete multiplayer card game project in 2020:

Game Requirements

  • Players can start and play the game without accounts (anonymous players).
  • Players invite others to play the game together by sharing a link.
  • Some aspects of the game are private to a player (hand), some are visible to everyone (discard pile, lay down melds), and some are not visible to anyone (draw pile).
  • Game state has to be immediately reflected on all devices,

Personal Requirements

  • I would like to stick to just web technologies and minimize the overall number of languages used between Backend and Frontend.
  • I don't want to pay for hosting if no one plays and minimize my exposure to underlying hosting infrastructure.
  • As this is a hobby project, I want to spend no more than 2 hours a day on it, ideally before work.
  • Just being able to play with my family and closest friends is enough. There is no need for a broader user base than that.

Not required for MVP

  • Leave the ability for a user to register their account for future versions. I want minimum friction when joining the game. Players should just enter their name and click start or join.

Non requirements

  • Being able to play the game offline.
  • Mobile version of the game, starting with web version only

Possible choices

Let's looks at few client and server side components we'll need for this game.

Client Side

Based on the requirements above and my experience with web technologies, this project will probably rely heavily on JavaScript. The ability to successfully run JS on Frontend and Backend these days is ideal for my needs.

As I built few personal and professional projects in React before, I immediately leaned towards using this library again. I have given serious consideration to Vue.js as well as it seems quite a popular choice these days. After a glance at their documentation looks like it might be even a simpler paradigm than React.

I remember from past projects that my biggest headache was the ambiguous use of the this operator inside React components which could be frustrating enough to use something else this time around. To my surprise, it turns out that new React Hooks pretty much eliminate the need for using it. Looks like I'm going to be sticking with React for one more project.

I like the type safety and TypeScript is pretty much a standard these days. It plays nicely with React so I know I'll want to start the project written entirely with TypeScript.

Results: React & Typescript

Server Side

The critical part of the project is ability to effortlessly synchronise the game state between the players on each move. To accomplish this all players should be connected to the server at all times and receive updates in realtime. This usually means connecting clients with websockets and pushing updates as they happen from the server. After quick research looks like there are several frameworks on the market that nicely wrap api in websockets that I could choose from.


  • Firebase
  • AWS Amplify
  • Supabase
  • Parse
  • and many others...

Oh boy... going through the feature list for each of these projects would take a while. I'm sure there are strengths and weaknesses in each of these platforms and some could try them all and see which one felt right for them. I do not want to spend time doing that. I've helped organizing a Hackathon at work and many teams used Firebase for their prototypes. The prototypes they created were quite impressive and I trust that they did their due diligence and there was obvious value in choosing Firebase.

Results: Firebase


Well I wouldn't call it a very scientific way of going about choosing technology stack for your personal project. Maybe technologies out there are mature enough and mistakes are harder to make these days. I think React, TypeScript & Firebase are pretty safe bets. I'll be happy to report if these choices were correct once I get deeper into the project.

Onto coding...