Going Servless

Part 4: A new type of backend for mobile apps

Typically we tend to think of the server+database as the single source of truth with all the business logic. The client apps periodically sync up with the server and cache the data locally. A team gets archived when the last player leaves the team. This piece of business logic follows these steps: The app notifies the server that a player has left a team and removes the team locally. The server then performs the check to see if this player was the last person on the team and archives the team. All the other client apps eventually sync with the server and remove the team locally.

Serverless Architecture

With a Serverless architecture, we remove the business logic from the backend and replace it with a database and a real-time syncing system to push data to all the client apps.

Let's review our example from above, the serverless implementation would follow these steps: The client removes the player from the team, see's this was the last player on the team and also archives the team locally. The app notifies the database about both the player and the team. These changes are then directly pushed to all the clients (in realtime) and the clients update their data locally.

This is great for systems where all the data manipulations depend on interactions from the client apps. Specifically in my case, every change to the database, every team that's created or deleted, every player that joins a new team or leaves a team is a result of an action performed on the app.

Handling Changes

Imagine the scenario:

  • v1.0 - when the last player leaves the team, delete the team
  • v2.0 - when the last player leaves the team, archive the team so it's not listed anymore, but keep the team in the records

If there are still players using v1.0 after v2.0 has been released, they would still be deleting teams.

Both serverless and traditional architectures have to deal with changes to the business logic that need to be propagated to all the systems. with serverless, using functions is a great option.

The term 'serverless' is often used synonymously with Functions as a Service (FaaS) systems, but they're quite different.

Functions as a Service

In my example, removing the last player from the team is just simple data manipulation, archiving the team is the side-effect that needs to be consistent across all the apps. To address side-effects, we can use Functions. These are simply units of business logic that run independently. With a serverless implementation, they are triggered by changes to the data, similar to pre-commit or post-commit hooks. In my case, I would create a pre-commit function that archives the team rather than delete the team.

A core feature of FaaS, is that they are only running for the duration of the function. The moment the function is triggered, a new instance is spun up, code is executed, and then the instance is shut down. Again this is great for systems where business logic is reacting to data changes and does not need to be running all the time.

Follow my thoughts, checkout projects that interest me, connect with me professionally or send me an old fashioned email.