Going Serverless with Node.js and Clean Architecture

Overview

Every time I start a project I discuss a lot with my team or myself (when on a self project) to find the best technology, architecture, patterns, and everything. This time, I wanted to build a self project to help on COVID-19, and so I started searching for new technologies and I found many great ones! I love working on project structures, so I always have some base code for each platform I use, such as, Android native app, Web development, server, etc. Of course technologies change a lot, too fast, and that’s the greater challenge! How can we keep ourselves updated on this second` changing world? Work overtime my friend, TANSTAAFL! :D

Three years ago, I worked with a serverless architecture project and the Serverless framework, and yet, I found out that this is the best approach for this project. Serverless architecture is great because it can scale (sky’s the limit) and I’d pay only for its use, so, if it gets too many users, I`ll have to pay for that many users, but, that means the application is a success and than, as this is a non-profit project, I`m pretty sure I might get help from somewhere to pay for those future bills.

I spent many hours on this structure, so, I think that, maybe, it could help someone. It might be a good starting point for new serverless projects. For this one, I used the Serverless framework with AWS Cloud Platform, Node.js, Typescript, DynamoDB, SQS and internationalization. The architecture tried (at least 😂) to follow the Clean Architecture proposed by Uncle Bob. This project (that will never be finished) can be found here, any thoughts on how to enhance the structure is VERY welcome (please!).

The Clean Architecture

If you are not very familiar with the clean architecture, go find out 😂… Just kidding, don`t worry, I don`t know that much too, we will never have a perfect architecture. What we can do is learn about many different architectures and adapt them to our project. Don’t try to fit your project strictfully to one perfect architecture, you will have future problems. One thing is very true, by defining layers and keeping them decoupled from one another makes the code cleaner, more testable and maintainable, that’s why I love Clean Architecture and many others that share the same strategy.

IMHO, the project architecture is just about patterns. We need to have design guidelines to develop software, we can’t have different approaches for one same thing. If you are a team member, you need to have the thought that the CODE IS NOT YOURS (Shit, I suffered so much with this)!! One needs to write code following the team design guidelines, you should not define a variable name using camelCase if everybody uses snake_case, please! 😑 (just one simple example)!

The Project Structure

The idea here is to follow the Clean Architecture proposed by Uncle Bob:

To achieve that, I used the following principles:
— Inner layer: entities;
— Second layer: use_cases;
— Third layer: app;
— Fourth layer: frameworks;

Inner layer: Everything related to the model itself. Basically, we have 3 files: the model, the schema and the validator. I put the validator here because it is only related to the model and is needed to build a user object.

Second layer: All use cases go here. When thinking of a RESTful API, basic use cases are the CRUD operations, but what if we need to inactivate a user? What if we need to append a new product category tag to the user after receiving a new order (thinking about an e-commerce system). Each of the examples given would be a new use case on the use_cases folder.

Third layer: Controllers and contracts. Controllers is the place where you will be able to implement your endpoints and Contracts are defined to make it easier to plug and unplug different databases, internationalization libs, queue clients, etc.. To use a different framework, just change the object on the project_dependencies file inside the config folder, peace of a cake! (Of course you need to implement the new framework first, not magic 😑).

Fourth layer: Frameworks. So you defined some contracts in the Third layer right? Now we need to implement them and here is the place. Here you can implement many different frameworks for the same contract and then just plug it in your project.

TL;DR

This base structure was created to speed up new serverless projects. This structure tends to be clean, to be testable, to be easy to maintain, append new features and change frameworks. Any thoughts on enhancements are super welcome. Use it or just take a look at it to implement your next project :)
Project can be found here. Thanks for reading!

Next Steps

— Test cases;
— Swagger API documentation;
— Log service;