Nanoservices, Microservices, Monolith — Serverless architectures by example
There are many different ways to structure your Serverless application.
In this blog post I’d like to show you three different architectural patterns you can use to setup your new Serverless application.
Note that the presented architectures are no strict rules you need to follow to setup a Serverless project architecture. They are suggestions you could / should follow.
However with Serverless in general you are free to organize your project in the way you’d like to.
Alright. Let’s take a look at the different architectures!
Nanoservices
The first architectural pattern is the so called “Nanoservices” architecture.
“Nanoservices” means that each functionality has it’s own API endpoint and it’s own, separate function file.
Let’s pretend we have a “users” resource and want to implement a CRUD functionality for this users resource. With “Nanoservices” we would architect our project like this:
You can see that each API endpoint points to exactly one function file which implements one CRUD functionality.
Microservices
Next up there’s the “Microservices” architecture.
“Microservices” aggregate functionality corresponding to a resource to one resource related function. The API endpoints remain the same:
You can see that we have one endpoint for each operation we want to perform on the resource. All those endpoints point to one resource function (in this case “users”) where resource related actions based on the call to the API are performed (e.g. “create a user”, “read users”, etc.).
Monolith
The last architecture is the so called “Monolith”.
A “Monolith” has only one endpoint and one large function. All logic is send to this one endpoint. The large function will perform the corresponding actions. All the functionality (regardless of the resource) will live inside this function. The request information which is sent to the endpoint will reveal which functionality on which resource should be triggered.
How could this work? You could e.g. use GraphQL to translate the incoming request to actions you want to perform.
Want to see real world implementations?
Take a look at the GraphQL boilerplate or the forum software Discuss.
Conclusion
Serverless gives us a great flexibility to organize our project the way we’d like to. We can use the architectural pattern which fits best to our development / deployment workflow.
We are also not forced to use just one architecture. All those proposed architecture can be mixed up altogether.
