Why this specific choice you may ask? NestJS and Gin are both used extensively and are great solutions for building production-ready Back-End applications.

Configuring NestJS with Fastify makes it one of the most performant setups for NodeJS. It could be a handicap for Go and Gin, unless Gin absolutely destroys one of the best solutions with NodeJS, performance-wise?

This article is built on top of a previous performance comparison for NodeJS, feel free to have a look.

Applications

Both applications provide the same functionalities, a basic newsletter with authentication, user management, and article management.

The NodeJS application is made on top of TypeScript, Prisma, and does some validation with class-validator.

On the other side, the Gin application is made with GORM, and uses the integrated validator.

They both provide authentication capabilities with JWTs and are configured with a PostgreSQL database.

Again, the database is hosted on AWS RDS, while the applications are on Beanstalk (on a t2.medium). If you read the previous article, you already know I'm about to use Artillery to run the actual performance tests.

Tests configuration

I'll apply the same strategy to both environments (with Nest and Gin):

Here, I'm creating a new user and logging in, before creating a new article and fetching different pages of articles (5 on each page). I still need a processor to generate users and articles with unique data:

If you don't know yet, Artillery works with a virtual user system. The number of virtual users can be configured, and one will be created per second, to execute the entire scenario you can see above.

In our current scenario, we have 6 requests:

• Register

• Login

• Create an article

• Fetch 3 pages

We can multiply the number of virtual users by 6 to get the request count per second (or 360 to find the count per minute, etc.).

Response time

To get started, we can run our performance test by simulating a medium load on our server. This way, we have exploitable results, without any of our Back-End actually failing.

To do so, 4 virtual users are enough (making 1.440 requests per minute if you don't feel like doing math). With Artillery, we can generate a nice visual report, with response time among other things:

I'm not a monster, I'll provide you with the actual values:

The first time I saw those values, I thought to myself:

Wow, it's looking grim for NodeJS

The Min and Max response time are interesting metrics, but that's not what I'm looking for here. You only need a single request to perform well or badly among thousands to get different results.

On the other hand, the median response time is an incredible metric, as well as p95 and p99. They respectively show us the maximum response time among the 95% and 99% of the best requests.

There, the Gin-based Back-End is indeed destroying the NestJS one, performance-wise. The difference is almost threefold, even I didn't expect that!

Making our servers crash

With the visual report from Artillery, we can also read the requests in timeout. It's a great indicator of when our APIs start to fail. I used the following configuration with my NestJS application:

Here, we have 4 virtual users during the first minute. Then, we go up to 5 users for 2 minutes, and 6 users for 2 more minutes. We can see the requests in timeout for NestJS below:

Here, we can see our server starts to fail around 4 minutes, when we use 6 virtual users (2.160 requests per minute).

We can observe a similar graph with the Go/Gin application, with... 14 virtual users.

Conclusion

I'm first and foremost a JavaScript developer, and have extensive experience on the NodeJS environment.

I worked with NestJS, Prisma, and everything around it for years now. I even have Prisma stickers and developed a library dedicated to unit testing it.

If I made some configuration mistake or introduced bad practices, it might be on the Gin application, not NestJS.

If there is one thing to remember for this exercise, it's that Go performs two to three times better with a handicap, compared to NodeJS.

NestJS with Express or Fastify?

If you aren't aware yet, NestJS is not an HTTP server framework by itself. It uses an actual server framework under the hood. It's configured by default with ExpressJS and provides easy integration with Fastify.

If you are just like me, you've read everywhere that higher-level frameworks tend to have lower performances. The features and ease of development often come with additional abstractions and processes, leading to a decline in performance.

But is that really true? Does Fastify indeed have better performance than Express? Also, what's the impact of using NestJS?

Applications

Luckily, I personally maintain four boilerplate projects with the same features, made with Express, Fastify, NestJS (with Express), and NestJS (with Fastify).

They're quite simple Back-End applications, a newsletter! To be more precise, they are made with:

• TypeScript

• Prisma and PostgreSQL

• Passport (and JWT) for authentication

• Class-validator for data validation

They provide a restricted set of functionalities:

• Authentication (Register, Login)

• Manage users (Update, Delete)

• Manage articles (Create, Delete, List, Detail)

Testing context

Once I have access to those applications, it's possible to performance test them, and compare the results. Before doing so, let's define the context of our tests.

First of all, the database will be hosted on AWS RDS, and the applications themselves will be on Beanstalk (on a t2.medium).

Then, we need a solution to actually run the performance tests and generate results. I do so thanks to the amazing Artillery.

Artillery Setup

You can find the complete Artillery setup on GitHub.

My strategy is quite straightforward. I'll set up four environments with the different applications, and apply the same scenario on each of them.

Here, you can see I:

• Create a new user

• Login

• Create a new article

• Get a list of articles

In order to run this script, I need to generate unique data. It's necessary to avoid creating a user with the same email, or articles with the same title. With Artillery, it can be done thanks to a processor:

Finally, I have three external configurations:

Those files define the number of requests done in different phases. Artillery works with virtual users, defined by arrivalRate. To be more precise, it defines the number of virtual users created per second.

The goal with those configurations is to simulate different levels of loads on our servers. This way, we can see the evolution of response time depending on usage. Also, with the failure-usage configuration, we can see at which point our server fails.

Running tests

With artillery, we can run our tests with the created configuration, for example with:

artillery run -o ./report-low-usage.json -c low-usage.yml -e fastify ./common-scenario.yml

Here, I'm running my main scenario, with the fastify environment, using the low-usage configuration. The results are then exported to ./report-low-usage.json.

I'm not really interested in a JSON file. Thankfully, we can generate a visual report based on it:

artillery report ./report-low-usage.json

We now have access to an HTML report, with the following information at the top:

I'm not really interested in this high-level overview, but we have access to more detailed results below. For example, we can have a look at the created virtual users:

Here, we have a report every 10 seconds of the created users. On average we have 20 users, which makes sense as we used the configuration with 2 users per second.

Then, we have the most interesting part of the report under http.response_time:

Here, we can find the response that took the least time, the most time, the median time, as well as p95 and p99. If you aren't sure:

• p95 defines the maximum response time among the best 95% requests.

• p99 defines the maximum response time among the best 99% requests.

Comparing performance

While the previous report is a great way to read a single result, it doesn't allow for easy comparison. Instead, I'll merge results from every application, and separate them by the simulated load.

Low load

First, we can have a look at the response time under a low load:

Here, we can find that the results are quite similar. The biggest difference can be found under the max response, but I don't think it's significant. A single max response is not a very good indicator as, all you need, is a single request taking longer.

Medium load

A more interesting report is for a medium load, closer to real-world usage. To be more precise, for the median, p95, and p99 responses:

This time, we have very interesting results. To be honest, they are even quite surprising! It seems like Fastify indeed has significantly better performance.

Not only has Fastify better performance, it seems like the NestJS counterpart for both Express and Fastify, have the same performance as the low-level http frameworks.

Failure

Because the third configuration overloads the applications until they cannot respond, the response time becomes unexploitable. Instead, on the default report, we have access to a errors.ETIMEDOUT section.

It tells us how many requests fail, but also when they start to fail. Below, you can find a comparison of the Fastify-based application (top) and Express-based application (bottom).

Here, we can see the Express-based application fails to answer requests earlier and more often than the Fastify application.

For Express, it starts to fail around 2 minutes, which corresponds to 5 virtual users on our configuration. For Fastify, it starts to fail 1 minute later, when we have 6 virtual users.

Interestingly enough, the results are exactly the same for NestJS with Express and NestJS with Fastify.

Conclusion

From those results, I have two main conclusions:

Fastify indeed has significantly better performance, which transposes to NestJS with Fastify.

NestJS is even better than I thought, not only does it bring us higher-level tools, but it barely has any impact on performance.

This article was originally a video. If you want to learn how to create production-ready Back-End application, have a look here.

Similarly to my Front-End implementation, I'm not satisfied with the available resources related to Clean Architecture. That's right, even on the Back-End!

What is Clean Architecture

If you stumbled upon this article, you probably know about Clean Architecture, but are looking for more information.

In the rare event of a beginner reading this article, I highly recommend getting started with the necessary theory.

What are we going to build

While I wrote this article, my goal was to test if Clean Architecture was as flexible as it promised. That's the reason I re-used the same entities and use cases as my Front-End implementation, and tried to move the infrastructure part to the Back-End with Express.

That means, the application is the same: a Tic-Tac-Toe game (in TypeScript). You will be able to send requests to a Back-End and play a complete game.

If you want to follow along with me, you can clone my starter project.

Behaviors

You can find the Front-End Tic-Tac-Toe on CodeSandbox to understand what the application is doing in practice. There are two main functionalities:

• Obviously, you can play a game of Tic-Tac-Toe.

• You can go back to a previous move (history) and play again.

Instead of being a Front-End application, we will provide endpoints with the same behavior.

File Structure

The original application already follows the idea of Screaming Architecture, with three directories:

• common/ includes all the shared source code.

• core/ defines the entry point of our application:

  • app.ts contains the ExpressJS server.

  • bootstrap.ts uses the code inside app.ts to build a server and listen to it.

• tic-tac-toe/ contains everything related to the game itself.

Files

While you can have a look at the entire project by yourself, please note there are three main files:

App

createApp is responsible for building the ExpressJS server and uses the Tic-Tac-Toe module (which is responsible for routing but is not the focus of this article).

Tic-Tac-Toe Controller

TicTacToeController is responsible for handling requests. It's the one that contains the business logic and the core part of the original implementation.

Board Service

BoardService takes the role of a data access object, which is an in-memory implementation for simplicity.

Define a Game Model

Similarly to my Front-End implementation, I like to start by defining a clear Domain Model. Its goal is to define the elements that make up our system. Please, keep in mind this is not strictly a part of Clean Architecture but Domain-Driven-Design.

For our game of Tic-Tac-Toe, we need:

• A board composed of 9 squares.

• Players and winners.

• At one point in time, the state of our game:

  • Is there a winner?

  • The history of moves (so we can navigate among them).

  • Who is playing next?

  • Potentially, the index of the last game played.

I'll create this file under tic-tac-toe/, using a namespace to make it clear:

Create the base structure for Clean Architecture

We will create an entity and use case in a minute. We can create the base classes for them under common/:

Keep in mind:

There are multiple ways to define those.

For Entity, I like to store properties inside a _data object and make it protected. It prevents developers from mutating it directly, which is a common source of issues. Depending on our needs, this class will definitely change.

There are multiple practices when it comes to use cases, but a very common one is to provide an execute method, which returns a Promise most of the time.

Create the Board Entity

Most of the logic of the Tic-Tac-Toe game seems related to the state of the board. Let's create an entity for it, inside a new entities subfolder, under tic-tac-toe:

Here:

• We store squares, based on the types from our GameDomainModel.

  • We add a getter to easily access the property.

• We already have the formula to calculate if player X plays next.

  • We copy it from the TicTacToe file inside the starter project.

  • We can calculate the current step based on the filled squares.

• The entity is also a great place to calculate if there is a winner.

We can also copy the formula from the starter TicTacToeController file.

In "Clean Architecture", Uncle Bob says:

An Entity is an object within our computer system that embodies a small set of critical business rules operating on Critical Business Data.

In our context, our critical business rules are the rules of the game of Tic-Tac-Toe.

Starting with our first use case

Now, we have everything we need to create an empty use case. We can get started with an obvious one, playing a move.

Obviously, it will take the square we play on. On the other hand, we also need to define the step we play on, as we can play on a previous move. Our use case will probably return an object similar to the game state:

We could probably use GameDomainModel.GameState as Output here. On the other hand, those objects may only seem familiar, and change for different reasons.

To be honest, the current code inside TicTacToeController is very similar to the future content of the Play use case. It might be because I created this project as another implementation, but the original project is still far from using Clean Architecture.

If you remember well, a use case shouldn't depend on a data access gateway from the Interface Adapters layer.

Add the board repository

Instead of the current BoardService, I'll define an interface as a port and its implementation will be an adapter. I'll also use the definition of Repository instead of Service for consistency.

Let's start with the interface by creating a sub-directory ports/ under tic-tac-toe/, with a file called board-repository.port.ts:

Then, we can create an adapters/ sub-directory under tic-tac-toe/. Also, the previous BoardService shouldn't be called BoardRepository.

It's not the implementation of IBoardRepository, it's one among others. To be more precise, it's an in-memory implementation.

Let's create in-memory-board.repository.ts:

Before we go back to our use case, we need one more thing: exceptions.

Exception management

If you look at the original TicTacToeController, you can see we throw exceptions when:

• The step we are supposed to play on doesn't exist

• We play on a square that's already taken

With Clean Architecture, we cannot throw exceptions that belong to the infrastructure layer (Interface Adapters & Framework and Drivers), from the use case layer.

Instead, we need to throw a Domain Exception, that is handled by the controller.

Let's define two exceptions, stored inside an exceptions/ sub-directory (itself inside tic-tac-toe/):

Complete our use case

Now that we have our entity, repository, and exceptions, we can complete our use case. Most of the logic can be transferred from TicTacToeController, in handlePlay.

There are a few changes necessary:

• Business rules are now inside the Board entity.

• We rely on the IBoardRepository.

• We throw a Domain Exception

This use case was added under tic-tac-toe/ in its own sub-directory use-cases/.

Adding missing use cases

The process is similar for the two other use cases. We can retrieve most of the logic from the TicTacToeController but use our brand new Board entity and IBoardRepository.

Let's start with jump-to.use-case.ts:

Then, we can add initialize.use-case.ts, which is responsible for starting a new game:

Binding use cases to a controller

The last part is definitely way easier in a Back-End environment. We simply need to:

• Execute the right use case

• If there is a Domain (or unknown) Exception, throw the related Application Exception

• Otherwise, return the result with the right status code.

Dependency Injection

Same thing here, using dependency injection is definitely easy. Depending on the Back-End framework you're using, you will have different solutions (or you can setup your own with InversifyJS).

In this example, I manually instantiate and inject dependencies from app.ts:

Using a presenter

If you look closely at our current controller, it's doing more than orchestration. It's also formatting data for moves, status, and squares, which is not really its role.

A better architecture would use a presenter instead. There are multiple ways to define a presenter. A common practice is to define a class with a format method.

Let's create presenter.ts inside common/:

Now, we need to define our actual presenter. It's supposed to present our game and return the related squares, moves, and status. Based on our current code, it needs the current history, winner, xIsNext, and step.

A controller shouldn't depend directly on a presenter but on its interface.

Let's create a game-presenter.port.ts inside tic-tac-toe/ports/:

Now, we can add the implementation, as game.presenter.ts inside tic-tac-toe/adapters/:

Completing controller

Now, we can expect our IGamePresenter inside the TicTacController constructor (which we instantiate and inject from app.ts). Then, we can remove the method related to formatting and instead use the presenter:

Conclusion

Your Back-End Tic-Tac-Toe game is now fully functional, and adheres to Clean Architecture! The domain (logic) is completely isolated from the infrastructure.

Feel free to look at the end result.

You would have no problem moving away from ExpressJS and using another Back-End framework like Fastify or NestJS. If you did, you wouldn't need to modify any code that's part of the domain layer.

Not only could you use another Back-End framework, but you could even make this game a Front-End application!

It emphasizes separation of concerns and independence of implementation details. Its goals include creating systems that are easy to modify over time.

To be more precise, it prioritizes high-level policies and business rules, keeping them independent of low-level details like frameworks and databases, enabling testability, and long-term sustainability of the software.

A great starting point for Clean Architecture is Robert C. Martin (Uncle Bob) blog post.

History behind Clean Architecture

The concept of Clean Architecture was first formulated by Robert C. Martin in his blog post from 2012. It was also popularised when he published his book "Clean Architecture: A Craftsman's Guide to Software Structure and Design" in 2017.

While Robert C. Martin was the one to define Clean Architecture, he didn't invent all the concepts it's built upon.

Hexagonal Architecture

One of the first references from the original blog post is Hexagonal Architecture (also called Ports & Adapters). It was originally a blog post, written by Alistair Cockburn, in 2005.

Essentially, it aims to decouple core business logic of an application from its external dependencies, such as databases, user interfaces, and external services.

The solution suggested by Alistair Cockburn is to define a clear boundary between the core logic and the external interactions, through a set of "ports" and "adapters".

Ports represent interfaces or contracts that define how the core logic communicates with the external world. On the other hand, adapters are implementations of these ports.

Onion Architecture

A few years later, in 2008, Jeffrey Palermo published about Onion Architecture on his blog. It also aims to decouple business logic from external dependencies but in a different way.

It does so by organizing the application into concentric layers, with the innermost layer representing the domain model or core business logic. This is how Jeffrey manages to isolate the core from external concerns like databases, frameworks, or UI.

To be precise, he defines 4 layers:

• Core (Domain Model): This innermost layer contains the domain model and business logic of the application. It encapsulates the essential behavior and rules of the system.

• Infrastructure (Domain Services): Surrounding the core, it provides implementations for interfaces defined in the core layer. It deals with external concerns like database access, framework integrations, and other infrastructure-related operations.

• Application Services: This layer orchestrates the interaction between the core domain and the infrastructure. It contains use cases or application-specific operations that coordinate the flow of data and actions within the system.

• Presentation/UI: It's the outermost layer, which handles user interface concerns. It includes components responsible for user interaction like controllers, views, or API endpoints.

In practice, Onion Architecture relies heavily on Dependency Injection. That's how the core can be independent from external implementations, and rely on abstractions defined by interfaces instead. This allows for loose coupling and easier substitution of components.

Others

Robert C. Martin talks about two main books, Lean Architecture: for Agile Software Development and Object-Oriented Software Engineering: A Use Case Driven Approach.

Both of those books influenced Clean Architecture but for different reasons.

Lean Architecture

In the first one, you'll read about Data, context and interaction. The main point is to separate the domain model (data) from use cases (context) and roles that objects play (interaction).

Object-Oriented Software Engineering

Then, in the second book, we focus on use cases. You can see them as a list of actions defining the interactions between an actor and a system, to achieve a goal.

Screaming Architecture

Another approach can be found as part of Clean Architecture: Screaming Architecture. It's a concept formulated by Robert C. Martin, who says:

If the plans you are looking at are for a single family residence, then you’ll likely see a front entrance, a foyer leading to a living room and perhaps a dining room. [...] As you looked at those plans, there’d be no question that you were looking at a house. The architecture would scream: house.

Then, he asks:

So what does the architecture of your application scream? When you look at the top level directory structure, and the source files in the highest level package; do they scream: Health Care System, or Accounting System, or Inventory Management System? Or do they scream: Rails, or Spring/Hibernate, or ASP?

He's not only asking rhetorical questions but has a great conclusion for us:

Just as the plans for a house or a library scream about the use cases of those buildings, so should the architecture of a software application scream about the use cases of the application.

Humble Object

If you read "Clean Architecture: A Craftsman's Guide to Software Structure and Design", you will learn about a new pattern: Humble Object. It was originally popularised by Gerard Meszaros in xUnit Test Patterns: Refactoring Test Code.

The idea is to separate the behavior that's hard to test from the behaviour that's easy to test. It's achieved by splitting a functionality into two parts:

• A humble part kept as simple as possible, that contains the hard-to-test code (usually dealing with problematic dependencies).

• A part that contains the logic or behavior that can be easily tested.

Component Design Principles

From a general perspective, large systems are built upon smaller components that are working together.

In his book on Clean Architecture, Uncle Bob gives us a set of principles that define how component should be composed together. While this is a broader subject, I definitely recommend you read about it.

Clean Architecture

There are a few concepts and rules that make Clean Architecture what it is today, as well as its specific layer organization. To get started, you can have a look at the following diagram:

I highly recommend keeping this diagram saved somewhere (or the original one from Robert C. Martin blog post). Thankfully, you don't have to understand everything about this diagram yet.

Right now, you will discover what those layers are, but will understand them more in-depth through practice. With time, you will come back to look at this illustration and find how much it makes sense.

As you can see, there are four layers, from the innermost to the outermost:

• Entities: They represent the essential business objects or concepts that are relevant to the application. In practice, an entity encapsulates the most general and high-level business rules and logic. They are completely independent of external concerns and are essentially the heart of the application's business logic.

• Use Cases (or Interactors): Use cases represent the application's behavior and define the actions that can be performed within the system. They encapsulate the workflow or the specific steps required to achieve a particular goal or perform a task. To be more precise, use cases orchestrate the flow of data and operations between the entities and the outer layers. Each use case typically corresponds to a specific user action or system operation.

• Interface Adapters: They act as the intermediary between the inner layers (Entities and Use Cases) and the outer layers (Frameworks and Drivers). They are responsible for translating data from the format most convenient for the use cases and entities into the format most convenient for the external frameworks and tools. This layer usually includes controllers in a traditional MVC architecture, as well as data mappers and gateways for external services.

• Frameworks and Drivers: The outmost layer consists of the external frameworks, tools, and devices such as the database, web framework, UI, etc. It deals with the delivery mechanisms and frameworks specific to the platform. It includes components such as web frameworks (Front-End or Back-End), databases, and other external systems and devices.

It's a common practice to call the group with Entities & Use Case "Business" or "Domain", while the group with Interface Adapters & Frameworks is called "Infrastructure".

The dependency rule

Probably the most important concept from Clean Architecture. In his blog post, Uncle Bob says:

This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle.

In particular, the name of something declared in an outer circle must not be mentioned by the code in the inner circle. That includes functions, classes. variables, or any other named software entity.

By the same token, data formats used in an outer circle should not be used by an inner circle, especially if those formats are generate by a framework in an outer circle. We don’t want anything in an outer circle to impact the inner circles.

Now, you might ask: how is this possible? For example, when a use case needs to communicate through an adapter (defined inside or outside of its layer).

This issue is solved thanks to Dependency Injection. Usually, an interface is defined inside an inner layer, and implemented inside the outer layer. This structure is illustrated in the bottom right of the Clean Architecture diagram.

There, we can see the use case (or interactor) uses a presenter, which belongs to an outer layer. In order to conform to the Dependency Rule, the use case depends on an interface defined in its own layer. The actual presenter is implemented in the outer layer.

Common misconception

Data Access

While it's tempting to define data access gateways inside the Framework & Drivers layer, that's not where they belong! Simply because you use a framework or driver to request your database doesn't make your gateway part of the outermost layer.

The important characteristic is how data flows: it's a gateway for data access. It's pretty obvious in the Clean Architecture diagram: it belongs to the Interface Adapters layer.

Controller

Often, if you try to adhere strictly to Clean Architecture, you will have a problem with the definition of your controller. In most applications, controllers use some sort of functionality from a framework, making it incompatible with the interface adapter layer.

The truth is: controllers can have a role that spans multiple layers. They are usually a part of both the Framework & Driver and Interface Adapters layer. In practice, you could make them independent of the Framework & Driver layer by:

• Splitting every controller in two (one in each layer)

• Converting the response format from one layer to the other.

Again, in practice, this is a terrible idea that has multiple downsides without bringing any real value.

Presenter

The presenter is not a common concept and can be quite confusing at first. It's defined by Robert C. Martin in cooperation with the view (in the context of UI) and is introduced at the same time as the Humble Object pattern.

That's because the view should be treated as the hard-to-test, humble object, while the presenter is the testable object. To be more precise, the presenter is responsible for formatting data that is passed to the view.

That also means the view should be kept as simple as possible.

The presenter is sometimes confused with the controller in Front-End applications. They have a completely different role: while the controller orchestrates the actions taken by an actor with the use cases, the presenter formats data received by the view.

Crossing boundaries

Uncle Bob is very clear when it comes to data crossing boundaries. Not only should you use Dependency Injection to respect the Dependency Rule, but you should also be careful about what type of data goes from one layer to another.

In his blog post, we can read:

Typically the data that crosses the boundaries is simple data structures. You can use basic structs or simple Data Transfer objects if you like.

You don't want some data structure that comes from a framework or library to go around your different layers. Instead, you want to convert them to simple data structure.

In the same blog post, there is also:

We don’t want to cheat and pass Entities or Database rows.

Be careful about entities, this is not an absolute rule. For example, the default practice is to return entities from your data access gateway (usually repositories by the way).

On the other hand, 99% of the time, you don't want your entity to leave the use case layer. An acceptable exception could be if you have specific entities related to authentication, which are heavily used at the controller level.

Otherwise, most of the time your entities leave the use case layer, it's an architecture smell.

Only 4 layers?

While Clean Architecture is presented with 4 amazing layers, it can be changed depending on your application needs. While it's not common, removing a layer can simplify your architecture, even though it could lead to decreased modularity and flexibility.

Adding a layer is also entirely possible. Sometimes we can find an added Domain layer, which sits between the Entities and Use Cases layers.

The Domain layer typically contains domain-specific logic and rules that are fundamental to the problem domain being of the application. This layer helps to keep the business logic isolated and cohesive, making it easier to understand and maintain.

In practice

I highly recommend you have a look a two other articles that explain how to implement Clean Architecture. They are both a Tic-Tac-Toe game for:

• Front-End with ReactJS

• Back-End with ExpressJS

What Clean Architecture is not

Domain-Driven-Design (DDD)

Often, we find concepts that originate from DDD discussed in Clean Architecture spaces. For examples:

• Domain services

• Domain events

• Domain-specific value objects

Are all rooted in Domain-Driven-Design. While they can be a great addition to Clean Architecture, they're not strictly a part of it.

CQS/CQRS

Often, instead of use cases, you will find commands and queries in applications made with Clean Architecture. They are principles that come from CQS & CQRS, which have a great synergy with Clean Architecture.

Similarly to concepts from DDD, they are homework not directly a part of Clean Architecture.

Difference with Onion Architecture

Even though Onion Architecture looks similar to Clean Architecture, there are fundamental differences between both:

• Layer Organization: Onion Architecture organizes layers based on their roles (core, infrastructure, application, presentation), while Clean Architecture organizes layers based on the flow of data and dependencies (entities, use cases, interface adapters, frameworks/drivers).

• Dependency Direction: In Onion Architecture, dependencies are typically inverted, with the core depending on abstractions defined in higher-level layers. In Clean Architecture, dependencies flow inward toward higher-level policies and business rules.

• Focus: Onion Architecture focuses on separating concerns through layered architecture, while Clean Architecture emphasizes dependency management and separation of concerns based on data flow.

Are looking for more in-depth resources about Clean Architecture? Let me know here.

It's also one of the requirements to understand Clean Architecture. That's the reason multiple pieces of knowledge come from Clean Architecture, which makes use of other references such as A Use Case Driven Approach or Lean Architecture.

Prerequisites

SOLID

Inside this article, lots of principles you will learn are actually derived from SOLID (but applied to components). You definitely need to understand it first, before reading any further.

Classes

In the following part of this article, and probably most articles about architecture, you will read about organizing classes.

It definitely makes sense if your whole application is built on top of OOP, but might get you to second-guess information when your code is not using classes.

Feel free to substitute classes for the structure you are actually using (be it functions, or anything else).

What are components?

A very simple definition of a component is a unit of deployment, which is the smallest entity that makes up a system. In practice, components take different forms depending on the language they are made with.

In interpreted languages, they are aggregated source files. On the other hand, they are closer to binary files with compiled languages (JAR files for Java or gem files for Ruby).

In the end, components can be used together to form a complete system. Potentially, they can be independently deployable, but more importantly, independently developable.

While those definitions are quite abstract, they include all the possible forms of components. In practice, we can think of components as part of this practical but non-comprehensive list:

• Multiple applications working together to create a system

• Packages (or libraries)

• Group of source files (sometimes called modules)

Cohesion

When it comes to Component Design, you will often get asked "Which classes belong to which components? ". Usually, those decisions are made based on context, but three main Component Cohesion Principles help you give a better answer.

Reuse/Release Equivalence Principle (REP)

This principle tells us components should only be re-used when they are tracked through a release process (and given an identifier when released).

Obviously, it's necessary to ensure components work together when new versions get released. Developers must be told when a new version is released, as well as which changes are included. Only then can they decide whether to use a new version or not.

As a general rule of thumb, all the elements that make up a component should be releasable together. They must be grouped because it makes sense to users, but "making sense" is not precise enough advice, hence the following two principles.

Common Closure Principle (CCP)

The Common Closure Principle can be seen as the Single Responsibility Principle, applied to components:

Gather into components those classes that change for the same reasons and at the same times. Separate into different components those classes that change at different times.

To be more straightforward, components should not have multiple reasons to change (just like a class). In the end, the same challenges apply:

• It's easier for maintainability to gather all the changes in a single component, instead of many components

• When changes occur in a single component, you only need to (re)validate whoever uses this specific component.

Common Reuse Principle (CRP)

The Common Reuse Principle is closer to the Interface Segration Principle, albeit more generic:

Don't force users of a component to depend on things they don't need.

Like the previous principle, it helps decide which classes and modules should be placed into a component. Typically, you will find classes with multiple dependencies between each other.

On the other hand, this principle also tells us which classes should not be kept together. From a general standpoint, classes that are not tightly bound to each other shouldn't be in the same component.

Don't depend on things you don't need.

Tension Diagram

If you understood those principles correctly, you realized they have an incompatible relationship with each other: REP and CCP are inclusive, while CRP is exclusive.

Everything is about balance, which in this case, is called tension between the three principles:

The goal of any great architect is to find the right place on this tension diagram for its current system. Focusing too much on REP and CRP will cause too many components to be updated when a change is made. On the other hand, focusing solely on CCP and REP will increase the number of necessary releases

Coupling

In the previous section, we talked multiple times about the relationship between components. But how exactly do we design those components, their relationship, and how coupled they are?

Acyclic Dependencies Principle (ADP)

It's mandatory for components to have no cycles in their dependency tree. Take the following dependency graph for example (where components are nodes and dependencies are edges):

No matter which components you take and follow dependencies, you will always end up with entities. It's impossible to follow dependencies back to the same component.

In other words, this dependency graph has no cycles, it's a directed acyclic graph.

When a new version of a component is released, it's easy to find out which components are affected: you can follow the dependencies backwards.

Teams responsible for the affected components need to validate everything works fine with the new version. The unaffected components don't need to undergo the same process.

Now let's take another example:

Here, we can see a new dependency between Entities and Authorizer, adding a cyclic dependency to this graph. Immediately, we face new issues.

When a new version of a component is released, it has to be compatible with many more components. For example Database must ensure it works not only with Entities, but also Authorizer.

That's the case for every component that uses Entities, including Interactors. That also means Entities cannot be built in autonomy, but must integrate with Authorizer and Interactors. Generally, testing and releases are rendered bothersome.

To avoid cyclic dependencies there are two main solutions:

• Use Dependency Inversion Principle (DIP)

• Instead of adding a new relationship between two components, create a new component, they both depend on.

But don't forget:

Allow no cycles in the component dependency graph.

Stable Dependencies Principle (SDP)

Components and their relationship are volatile by design. Following the Common Closure Principle leads us to create components affected by some changes and immune to others.

As a general rule, a volatile component shouldn't be depended on by a component that is difficult to change. Otherwise, the volatile component will be difficult to change as well.

Be careful, a module that is easy to change can be made difficult to change when depended on by a volatile dependency.

That's the reason the Stable Dependencies Principle tells us:

Modules that are intended to be easy to change should not be depended on by modules that are harder to change.

Usually, a component will be harder to change (or stable), when it is depended on by multiple dependencies. It will also tend to be more volatile when it depends on more dependencies.

Another way to understand the Stable Dependencies Principle is the degree of volatility should decrease the deeper you go into the dependency graph.

Unfortunately, it will happen that one of your stable components depends on one that's volatile. Similar to the previous principle, it's possible to solve this issue by:

• Using Dependency Inversion Principle

• Creating another component depended on by the other two.

To make it more simple:

Depend in the direction of stability

Stable Abstraction Principle (SAP)

Usually, some part of a software is made to rarely change. That's what we call high-level policy. This type of business and architecture decision is intended to be stable, not volatile.

However, if the code for those policies is placed into a stable component, it will be made hard to change. Sometimes, you will need to have a stable high-level policy, which implementation should be easier to change, but how?

We can get some inspiration from the Open-Closed Principle (which is part of SOLID). It tells us it's possible (and desirable) to create classes flexible enough to be extended without requiring modification: Abstract classes.

This is where the Stable Abstraction Principle comes in. It defines a relationship between stability and abstractness:

• A stable component should also be abstract so that its stability does not prevent it from being extended.

• An unstable component should be concrete (not abstract) since its instability allows the concrete code within it to be easily changed.

In turn:

If a component is to be stable, it should consist of interfaces and abstract classes so that it can be extended.

If we combine the Stable Dependencies Principle and Stable Abstraction Principle, we are able to make a component partially abstract or stable. There is no perfect level of abstraction or stability, it depends on the policies you wish to express.

What you should aim for, is the right level of abstraction compared to the level of stability necessary for your components.

For example, a component that is both stable and concrete will be painful to maintain. It can hardly be extended because it's not abstract, and very difficult to change because it's stable.

On the other hand, a component that is both volatile and abstract will probably be useless. That means it expresses abstract policies, which nobody depends on.

Do you want to learn more about Clean Architecture? Let me know here.

In this article, I give you the necessary knowledge to get started efficiently with Docker, and resources to look at in the future, but you definitely need practice to get there.

What is Docker?

From the Docker documentation, we learn:

Docker provides the ability to package and run an application in a loosely isolated environment called a container.

That's a great definition of what Docker actually is, but if you're just getting started, it might not be easy to understand. Instead, I would like to describe Docker (and containers) in opposition to virtual machines.

Virtual Machine

Maybe you worked with virtual machines in the past, and they are definitely easier to approach.

They can be seen as software that simulates (or virtualizes) a separate environment, on a host machine. For virtual machines, it's possible to interact with physical components (almost) directly and allocate dedicated processors or memory for example.

To be more precise, virtual machines use a piece of software called hypervisor to interact with the physical part of your computer.

In the end, it allows you to simulate a complete operating system, separated from everything else. On the other hand, it makes it heavy by nature, as it simulates a complete environment, using a hypervisor (even though lightweight).

Container

A container (of which Docker is a provider, but there are alternatives) is slightly different. It achieves the same goal of virtualization but with another strategy.

Instead of building a complete virtual machine, a container can be seen as a package that contains everything needed for your system to work. That often includes a light operating system, runtime libraries, and your code.

Containers still work in separate processes but don't use an hypervisor. You can see the separation between containers as softer than virtual machines, which also makes it more performant.

To be more precise, instead of virtualizing physical components like virtual machines, containers only virtualize the operating system. They make use of the host operating system, its features, and its resources.

What problems does Docker solve?

Docker is a great solution to one modern challenge: automation. Because containers are lightweight, they can be easily built and deployed. It makes development, testing, and deployment faster hence cheaper.

Your applications often need a specific environment to run in. It includes an operating system (with a specific version), runtimes, libraries and frameworks, and sometimes more.

This is where the strength of containers, and Docker, is revealed. It makes it very easy to define the environment you need.

For example, setting up a new local environment becomes extremely fast and easy. Tests can run in the same environment, as well as deployment to minimize issues with your infrastructure.

Theory with Docker

To get started, there are three main concepts to understand with Docker:

• Dockerfile

• Image

• Container

Container

Previously, we only talked about containers, which are the final building blocks. At this point, you should understand they are a running piece of software packaged with your application and all the necessary dependencies for it.

Usually, you give access to the application running on your container to the host machine so it becomes usable. But how do we get there?

Image

If your container is actually running, based on a package with everything you need, the previous step is to build the necessary package.

Docker comes with the concept of image, which is exactly what you would expect from a package, a binary with all your dependencies.

Images are built on top of each other. For example, the most basic ones only provide a lightweight operating system like Ubuntu, Debian, or Alpine.

A more advanced docker image is node, which includes the NodeJS runtime on top of Debian (by default). Typically, you would build your own image on top of this one, and include your source code.

At this point, you might have one remaining question:

How do we define the content of an image and build it?

Dockerfile

Docker works with a configuration system based on a text file called Dockerfile. The first example from the introduction is for a go application:

# syntax=docker/dockerfile:1
FROM golang:1.20-alpine
WORKDIR /src
COPY . .
RUN go mod download
RUN go build -o /bin/client ./cmd/client
RUN go build -o /bin/server ./cmd/server
ENTRYPOINT [ "/bin/server" ]

The first FROM instruction defines the base image we are building on top of. Those images usually come from DockerHub, where you can upload your images.

Then, the WORKDIR instruction defines the working directory, where we will run commands by default.

COPY is used to copy files from the host machine to the image, usually the source code.

As the name suggests, RUN is responsible for running commands on the image in the process of being built. In this example, go is used to install dependencies and build client and server applications, based on code copied previously.

Finally, ENTRYPOINT defines the default command used when starting a container based on this image. It's necessary, as you often need to start your application with the container, and a container will stop if the main process is not busy.

You can find more references in the Docker documentation.

Using Docker

Now that you have a better understanding of Docker, you have to actually write Dockerfiles, build images, run containers, and more!

Setup

At this point, you will have to install the Docker engine and use its CLI.

Please, clone this project, which we will use in the next part. It's a simple NodeJS backend application that answers with "hello world" on the root path (/).

Create a Dockerfile

Inside the cloned repository, I want you to create a file called Dockerfile with the following content:

FROM node:18.18.0

WORKDIR /app

COPY . /app

RUN yarn

EXPOSE 8000

CMD ["yarn", "start"]

In the previous section, we already explained most of the instructions we use in a Dockerfile. There are a few differences here:

• We are using an image for NodeJS with version 18.18.0.

• We install dependencies with yarn (instead of using go).

• We expose port 8000, which makes it accessible from outside the container.

• We start the app with yarn start.

Create an image

Now, you can open a console inside the same directory and run the command:

docker image build . -t hello-world

Here, we start with the docker command to access its CLI, image to access actions for images, and build to create the actual image.

It takes one argument with the path to the directory with the Dockerfile to build into an image, "." for the actual directory.

While it's not necessary, the "-t" flag defines the name (and optionally :tag) for the generated image. You can have a look at the full documentation for the image build as well as all the commands for image.

List images

Another useful command is to list images, thanks to the image ls command:

docker image ls

It's not the command you will use the most, but keep in mind it exists, mainly if you want to clean memory taken by docker.

Introduction to containers

While you can create and start a container separately, a more common practice is to use run to do both at the same time.

We need to define which image to run our container with, but also define a port accessible on the host machine, and which port it corresponds to, on the container.

We exposed port 8000 from the Dockerfile, we can re-use it and link it to the same port 8000 on the host machine, thanks to the "-p" flag:

docker container run -p 8000:8000 hello-world

That's it, your container should be up and running. You can try to open http://localhost:8000 on your browser and should see a message with "hello world".

List containers

From another console, you can list containers and have multiple commands to do it. In theory, the official command is:

docker container ls

But the truth is, you can also use:

docker container ps

Which can be shortened, and is the most used:

docker ps

No matter which exact command you are using, you can add the "-a" flag to list all containers, including the stopped ones:

docker ps -a

Stop a container

Among the information displayed when listing containers, you have access to the container ID.

After finding the ID of the currently running container, you can use the stop command:

docker container stop [CONTAINER ID]

Start an existing container

You can use the start command:

docker container start [CONTAINER ID]

Interact with a container

During your day-to-day work with Docker, you often need to interact with your containers. It can be to see what's going on, move files around, etc.

You can use exec to run a single command on a container:

docker container exec [CONTAINER ID] [COMMAND]

For a more complex use case, it's possible to keep a console attached and interactive with your container.

It's done thanks to the interactive and tty flags (found in the exec documentation). To be more precise, you can open an interactive console, using the basic sh command.

The interactive and tty flags can be shortened to "-it":

docker container exec -it [CONTAINER ID] sh

To easily leave the interactive console, you can use CMD + D.

Free disk space

If you are working heavily with Docker, but don't have a huge amount of available disk space, you might use it all.

Keep in mind you have access to a prune command for images and containers, which can come in handy.

Docker Compose

While using Docker by itself is a great start, I bet you will very quickly need Docker Compose.

If Docker allows you to manipulate images and containers, docker-compose makes it possible to manage multiple containers and make them work together.

Setup

From a general perspective, Docker Compose works with a configuration file that defines how your containers interact with each other. If you have Docker installed, you should also have Docker Compose and its CLI.

For this exercise, please clone a todo backend made with NodeJS. It needs a PostgreSQL database, which means we also need to run migrations with Prisma.

Dockerfile

We will use a slightly different Dockerfile for this example:

FROM node:18.18.0

RUN apt-get update && apt-get install tini

WORKDIR /app

COPY . /app

RUN yarn

EXPOSE 8000

ENTRYPOINT ["/usr/bin/tini", "--"]

Here, we are installing and using tini, which mainly keeps the container alive and improves signal forwarding.

We are not starting the app here, but that can be configured inside the docker-compose file. It's necessary, as starting the app requires access to a PostgreSQL database.

Compose configuration

While there are more advanced features inside Docker Compose (and Docker, such as networks and volumes), we will focus on services.

While services are more complex in reality, you can see each of them as a definition for a container. Here, we need two containers:

• One with a PostgreSQL database

• Another with our application, which depends on the first

Good news, there is a postgres image, which can be easily used. We can define our services with this image first:

services:
  postgres:
    image: postgres:alpine
    restart: always
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
    ports:
      - '5432:5432'

Then, we can add a service for our hello-world application, and configure it with its Dockerfile. It can be done using the build property, which takes the path with the necessary Dockerfile:

services:
  postgres:
    image: postgres:alpine
    restart: always
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
    ports:
      - '5432:5432'
  hello-world:
    build: .

Unfortunately, that's not good enough, we need to:

• Configure the necessary environment variables.

• Configure the container port to the host machine port.

• Start the application, which should access the container for postgres.

services:
  postgres:
    image: postgres:alpine
    restart: always
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
    ports:
      - '5432:5432'
  hello-world:
    build: .
    environment:
      - DATABASE_URL=postgres://postgres:postgres@postgres/express-todo
      - PORT=8000
      - NODE_ENV=development
    depends_on:
      - postgres

Here, we configured the environment variable, using the username and password postgres, as configured in the first service.

We also use postgres as hostname for the database, which is provided by Docker Compose, as the service itself is called postgres.

We use PORT 8000 and NODE_ENV development as it's necessary for our application, but the most important part is not environment, but the depends_on property.

It's used to define the dependency relationship between services, hence which services are started when another one is, and in which order.

Finally, we can add the startup command:

services:
  postgres:
    image: postgres:alpine
    restart: always
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
    ports:
      - '5432:5432'
  hello-world:
    build: .
    environment:
      - DATABASE_URL=postgres://postgres:postgres@postgres/express-todo
      - PORT=8000
      - NODE_ENV=development
    ports:
      - '8000:8000'
    command: >
      sh -c "yarn prisma migrate deploy
      && yarn build
      && yarn start
    depends_on:
      - postgres

With this syntax, we can define a command on multiple lines. Here, we are running migration with Prisma, building the app, and starting it.

Starting services

For Docker Compose, you can find the complete list of commands. What we need right now is simply up:

docker-compose up

Once the application starts, you should be able to access http://localhost:8000/todo, which returns an empty list for now:

Good practices

This article was a good introduction, but I definitely recommend you have a look at an article on performances, and more generally good practices with Docker.

Today, I want to show you how to improve from a basic to a very efficient Dockerfile, step by step.

Getting Started

It’s a very short Dockerfile, which has the advantage of being simple while working perfectly fine. It does the job of:

• Using the latest version of the official NodeJS image as a base

• Define a working directory (/app)

• Copying source files

• Installing dependencies

• Exposing port (8000)

• Running the app (yarn start)

But is it efficient? Obviously not. If it was, there would be no point to the article you’re about to read.

Parent Image

Here, there are three important points.

Using a fixed version

Maybe it seems like a good idea to use the latest version of an image as a base (to stay up-to-date), but it’s not. In practice, it’s often the source of issues.

If you use the last version of an image (latest), you don’t have control over when it gets updated. It’s possible (and will happen) that a new version of an image is published while being incompatible with your app.

Between two builds, your application will suddenly go from working to failing, without any apparent reason.

That’s why we prefer using a fixed version instead of “latest”. But that also means you have the responsibility to update your base images from time to time.

Long-Term-Support

Usually, a software is provided with specific LTS versions. That means creators provide better support for those versions, and should be preferred.

NodeJS provides a list of LTS versions on its official website.

Alpine

Docker images are built on top of a given distribution, such as Ubuntu and Debian. Among those distributions is Alpine.

It’s known for being very lightweight compared to others and is a huge help in keeping an efficient image.

Lower Privileges

The default user being ROOT, he has unlimited access. For security, it’s a better idea to provide a user with limited privileges.

Fortunately, with the node image comes a user called… node.

Working Directory

The working directory is the one used by default. It’s a good idea to define a specific one for your app.

The most common practice is to use /usr/src/app.

Caching

Docker works with a caching system, which is often ignored. You can think of each step in a Dockerfile as a layer, which is cached.

When one layer changes, all subsequent layers are invalidated. When the image is rebuilt, instead of retrieving a layer from the cache, the necessary command is simply restarted.

One layer changes frequently: the source code. So it’s best to copy the source code as late as possible.

The most common mistake is to copy the list of dependencies at the same time as the source code, then install the dependencies.

In this case, every time the source code changes and the image is rebuilt, the dependencies will be reinstalled. That’s why we prefer to copy the files defining the dependencies first, then install them, and finally copy the source code.

Configure the Working Directory

Previously, we defined a new Working Directory and set up a user with limited privilege. That means we need to create the necessary directory first and give necessary access to the node user.

Update Package List

With Alpine, we aren’t using APT, but APK to manage packages. No matter which tool you use to manage packages, you need to update its list from remote repositories.

That way, you ensure no out-of-date packages are installed. It’s mandatory to avoid packages with security and performance issues.

Adding Packages

I recommend using the — no-cache flag to avoid generating cache you won’t use, but will still make your image heavier.

Multiple RUN

Inside Best practices for writing Dockerfiles, we learn to:

always combine RUN apt-get update with apt-get install in the same RUN statement.

Using apt-get update alone in a RUN statement causes caching issues and subsequent apt-get install instructions to fail.

For more information, I highly recommend you give best practices a read.

Entrypoint

I like to keep a basic Dockerfile that doesn’t start my application directly. Instead, I use Tini, which keeps the container alive and improve how processes are managed.

Then, you can either use multi-stage builds to augment your basic stage, or start and configure your application from outside the Dockerfile.

Locally you can use the Docker CLI. Also, when you deploy your app, any container management system allows you to configure startup scripts.

That way, you can have a single Dockerfile that is used in different configurations, instead of multiple configurations with barely any difference.

It becomes the source of truth about which environment your app run on.

Final Result

Now, you might be wondering: what’s the difference?

Apart from better security and faster re-build, one of my real-world project is 1GB lighter with the improved image:

Do you want to learn more backend skills, you can effectively use in a professional environment?

Cover photo by Thais Morais on Unsplash

First, we need to define the basic properties of micro-services. Amazing resources like Building Microservices and Microservice Architecture tell us they are supposed to be:

• Small in size

• Messaging enabled

• Bounded by contexts

• Autonomously developed

• Independently deployable

• Decentralized

• Built and released with automated processes

• Loosely coupled

• Focused on one thing

If you built your back-end with micro-services in mind, but don’t respect some of those properties, it’s an obvious sign you made a mistake.

But sometimes, wrong architecture choices sneak up on you. You end up with something close to micro-services but don’t respect some of their rules.

Distributed monolith

The most common is to build a distributed monolith instead of micro-services. This is a complete subject in itself, I highly recommend you read more about it.

Shared database

Let’s get this straight: it’s impossible to create independent and loosely coupled services with a shared database.

You will quickly realize how shared ownership of a database is a nightmare and has a negative impact on development and maintenance. It doesn’t integrate too well with ORMs, and I’m not even talking about deployment.

Yes, in a monolith you can have a single database, which makes things easy. With micro-services, you don’t have a choice but to make it more complex by separating databases for each service.

It’s one of the trade-offs with micro-services, it’s an added complexity that allows you to take advantage of micro-services.

Lack of automation

Micro-services definitely require more effort to develop, deploy, and maintain. That’s why one of the cornerstones of your system should be automation.

I guess you could try to create a few micro-services without automation, but on a real project that’s simply unrealistic. Mainly, testing and deployment quickly become impossible without a completely automated CI/CD system.

Shared business logic

Sharing business logic goes against the properties expected from micro-services, as it makes your services highly coupled.

And, in practice, you will also realize it has fewer benefits than expected. Using a shared package for business logic forces you to update the package itself, before updating your services.

It makes development longer and causes context-switching for developers, without bringing any real value.

Starting with micro-services

In recent times, micro-services became trendy. While they solve several specific challenges, they’re not a silver bullet.

In practice, they should only be used when you already have a monolith, but have challenges micro-services solve.

Let’s say you started your back-end application, day one, as micro-services. There is a higher probability you did so because you wanted to use micro-services than to solve a real challenge.

Lack of tests

Micro-services should be tested as much, if not more, compared to a monolith.

They should be tested in isolation, but that’s not all. If your services communicate (usually through events), it means they agree on a contract (implicitly or explicitly).

This contract should definitely be a part of the scope of your tests.

Not independently deployable

If, for some reason, you are unable to deploy a new version of a service in autonomy, it’s an obvious sign your services are highly coupled.

You shouldn’t need the other services at any point in the development and deployment process of a service. In Hands-on Microservices with Kotlin, we learn:

Having the ability to deliver constantly is one of the advantages of the microservices architecture; any constraints should be removed, as much as we remove bugs from our applications.

We should take care of deployments from the beginning of the design of our microservices and architecture; finding a constraint on this area at late stages could have a big impact on the overall application.

Synchronous communication between services

Using synchronous (request-response) communication between services breaks the independent & loosely coupled properties.

If you use synchronous communication between services, you are actually building a distributed monolith. After reading about distributed monolith, you should know it’s the exact opposite of what we want.

It doesn’t bring the added value of micro-services but also loses the simplicity that comes with a monolith.

Moreover, with micro-services, we need to guarantee messages get delivered. With request-response communication, when a process extends to more than one service, it’s simply impossible.

Need for other services to work

Maybe the most important, but still the most often ignored.

One of the downsides of synchronous communication between services is the need for multiple services to work at the same time.

In theory, one service should be able to work perfectly fine even if all other services are down. Obviously, the system itself won’t work as expected, but services in isolation should.

This is generally made possible by:

• Limiting relationships between services

• Using deduplication

• Communicating through events.

If you are looking for an example projects with micro-services, you might be interested in a tic-tac-toe game and its score.

Otherwise, if you are looking for a more in-depth, and practical course on micro-services: Good news, I teach micro-services in a complete guide.

If you are unsure about the exact properties of micro-services and the challenges that come along, feel free to read about it more in-depth:

Authentication & Authorization

Actually, authentication is not the only step we have to manage, but also authorization.

If you’re not sure about the difference, Auth0 reminds us that:

In simple terms, authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.

In practice, you can see authentication as the process where you send your email and password. You usually retrieve something that identifies you as the user, which you send along with other requests.

That way, on every other request, the server knows who you are and what resources you have access to. He can then decides if you can access certain endpoints, this is authorization.

Now, I would like to differentiate authentication systems into two groups with different challenges. They are stateful and stateless authentication systems.

Stateful authentication

In a stateful authentication system, you need to retrieve the user’s information every time he’s making a request.

For example, after authentication, you can retrieve a unique id that ties you to a user in database. That way, the server can find who you are, without sending your e-mail and password every time.

But the server still needs to verify the user’s information that is tied to the unique id you’re sending. Only then can he decides if you can access a given resource.

That means, even if you’re sending a unique ID that identifies you, the server has to retrieve the user information before handling a request.

This authorization step becomes problematic when it comes to micro-services. If you’re doing micro-services well, you want to avoid high coupling, which implies two things (among others):

• Separate database

• No synchronous communication (request/response) between services.

That means, with the current state of things, we cannot authorize a user on a service outside of the one dedicated to authentication.

Now, we have to think about a way to make authorization possible but keep micro-services independent and lowly coupled.

There is one main solution: managing authentication through an API gateway.

Here, we use an API gateway whose role is to proxy requests to the right service. But, before proxying requests, it checks if the user sent an ID he wants to authenticate with.

If he did, the API gateway retrieves the data related to the user and adds it to the request before it gets sent to the right service.

For example, it encodes the user information inside a string, that is passed with a header.

This way, any service can decode the user information, without relying on the user service.

In my opinion, stateful authentication is simply not a great authentication system when it comes to micro-services.

It makes development and maintenance harder, has a bad impact on performance, and opens the door to security exploits.

While the previous solution is possible, I would prefer using a stateless authentication system.

Stateless authentication

In a stateless authentication system, the user’s information is stored by the client. That means, once you are authenticated, there is no need to retrieve the user’s information.

For example, a stateless authentication system can be set up using JSON Web Token.

Here, the process becomes much more straightforward. We generate a JWT by authenticating to the user service and sending it with requests to other services.

Other services don’t need to reach the user service as the user information is self-contained.

It makes everything simple by design and helps a lot in keeping our services completely independent.

While this is my opinion, it’s definitely my favorite way to handle authentication with micro-services.

If you are looking for an example projects with micro-services, you might be interested in a tic-tac-toe game and its score.

Otherwise, if you are looking for a more in-depth, and practical course on micro-services: Good news, I teach micro-services in a complete guide.

Cover photo by Max Harlynking on Unsplash

Today, I want to make it clear how JWT should be used in your authentication flow, what are its security vulnerabilities, and how to avoid them.

What is a JWT

From its introduction page, we learn the following:

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object

Content

In practice, a JWT is a string that looks like xxxxx.yyyyy.zzzzz , where the sections are respectively the header (xxxxx ), payload (yyyyy ), and signature (zzzzz ).

Header

The header is a JSON object, which typically defines the algorithm used, and the type of the token JWT. It’s encoded in base64 to be used as a string.

Payload

The payload is also a JSON object, where you define the user information. it’s also encoded in base64.

Signature

The signature is generated based on the header and payload, using an algorithm (such as HMAC SHA256) and your secret.

Result

In the end, you generate a JWT, which anyone can read the information of. But you are the only one able to verify a JWT has not been tampered with. Nobody can change a JWT payload and sign it with your own secret.

Processes

Authentication

In the authentication process, a user typically sends his credentials to an API, which tries to find the corresponding account in a database.

If an account is found, a JWT is generated with the user information, such as id, name, or even his roles (admin? user?).

Authorization

Then, a user is able to request a private endpoint, where he needs to be authenticated. This is known as the authorization process:

Because a JWT contains user information (it’s stateless/self-contained), the API doesn’t need to request a database. This is amazing in terms of performance, and even better on distributed architecture.

This is the normal use case of a JWT, if you’re making requests to your database during authorization, you defeat the purpose of JWT.

Limitations

On one side, the self-contained aspect of JWT makes it amazing. On the other, because you’re not requesting to your database, you cannot invalidate a JWT.

This is an issue for both functionality & security. If a user gets his token stolen, or if you have a role system and someone gets a role removed, he can still use a previous token when he shouldn’t be allowed to (while the token is not expired).

This problem is solved by limiting the lifetime of tokens to a short duration, such as 5 minutes. But you don’t want to ask a user credentials every five minutes.

That’s why you need to implement refresh tokens. It’s often treated as beyond the scope of basic learning materials, but it’s mandatory.

Refresh tokens

Refresh tokens are completely different from the regular JWT you use for authorization (which are called identity tokens). They are long-lived tokens (~7 days) and can be used a single time to generate a new identity token.

If you respect those properties, you can implement identity tokens in different ways. You can have a table that stores refresh tokens and the corresponding user, which is updated every time it’s used.

For refresh tokens, I usually generate a JWT where the payload contains two properties, a sub, and userId. The sub contains a UUID, which is stored in a database, and map to its corresponding user.

When a user tries to log in based on a refresh token, I find the corresponding sub in my database and verify the userId it maps to is the right one (it avoids a potential situation where a user connects with a previous user refresh token UUID).

In the end, you should have two endpoints for login, one with user credentials, and one with a refresh token. Now, there are multiple ways to generate and store those tokens, which leads us to the next section: vulnerabilities.

Security vulnerabilities

XSS attack

There is one implementation issue I’ve seen too many times, how to store a JWT. In most online examples, you can see a JWT being returned inside a request response (body), and stored in localStorage or simply in memory.

This is the source of a huge security vulnerability, XSS attack.

An XSS attack is possible when a malicious third party manage to inject code inside your application.

From here, anything allowed by your runtime is possible. A third party could secretly read the content of localStorage and send it to their own server, stealing JWTs for example.

Storing your JWT in-memory isn’t enough. A third party can easily intercept a request response, and read users JWTs from there. There is a single solution: storing them inside secured cookies.

A secure cookie is configured with, at least, the Secure and HttpOnly attributes. It’s also a good practice to use SameSite to avoid CSRF.

There is also some arguments in favor of storing refresh tokens inside localStorage instead of cookies. The impact of a refresh token being stolen is reduced by its one-time only validity.

CSRF

Cookies are much better than localStorage for our use case, but they’re not perfect. With cookies, you don’t control when they are sent, your browser sends them with every request.

It’s the source of CSRF, short for Cross Site Request Forgery.

From a general perspective, CSRF can happen when a third party trick a user into making a malicious request. The CSRF page from OWASP gives an amazing scenario with a bank transfer endpoint.

Using cookies with SameSite mitigates CSRF, but only a CSRF token can completely get rid of it.

Signing

There are two potential vulnerabilities when you sign a JWT token, bad algorithm and secret key.

JWT can be signed with different algorithms. The list can differ depending on which library you are using. Library authors are responsible to implement those.

The default algorithm is usually HS256, but using a bad implementation or wrong configuration might end up with you using the none algorithm.

What this algorithm does is… nothing! It generates an empty signature, which allows any third party to modify the JWT payload, and your server will still believe the modified JWT is valid.

My advice is to use well-known/maintained libraries and not try to use the none algorithm. You can also verify the content of tokens you generate using jwt.io.

Previously, we talked about refresh tokens, but there is a vulnerability introduced by using different types of tokens.

If you configure your refresh tokens to be signed with the same secret as the identity tokens, a malicious user could send an identity token where you expect a refresh token and vice-versa.

Depending on your implementation, you might grant access to a malicious user where you shouldn’t. There is a single solution: use a different secret for your identity & refresh tokens.

Validation

During the validation phase, bad implementation could introduce security vulnerabilities.

There is an example with the NodeJS jsonwebtoken library. The right implementation is to use the verify method to ensure the token is valid and decode it.

On the other hand, it provides a decod method that doesn’t check if the token is valid. Some developers not used to working with JWT might use the second method instead, virtually accepting any JWT token.

Ensure you are using well-known libraries and learn them properly before implementing anything sensitive.

Author’s note

I advocate for the use of cookies over localStorage to mitigate XSS attacks, but that’s not a reason to ignore potential XSS attacks altogether. I definitely recommend following good practices regarding XSS attacks.

For example, using JS eval should be avoided. You can also verify your dependencies using tools like snyk.io, and only use trusted CDN.

Building your own authentication system is an arduous task, I would recommend anyone to either use an authentication provider such as Auth0, or have a dedicated team working full time on authentication.

Do you want to learn how to create a backend application, add a secure authentication system, and much more?

Cover photo by Edwin Hooper on Unsplash

First, we need to understand the difference between a simple monolith and micro-services.

Monolith

Impressive only by name, monolithic is the most common architectural style. It’s when everything is contained in a single piece, or in other words, self-contained.

Architecture

In practice, a monolithic backend looks like a single and large codebase that provides all the APIs you need

Now, the questions are, why is monolithic the traditional architecture, and why would you want to create micro-services instead?

A monolithic architecture comes with much more simplicity at the beginning of a project and is sufficient for most projects.

When your whole codebase is in the same place, development, testing, monitoring, and deployment are much more straightforward, faster, and cheaper.

Challenges

But when your application grows, with more functionality and users, new challenges appear. They could be gathered under two main categories, codebase maintainability and scalability.

In a monolith, it's a common practice to organize code by creating abstractions, such as modules.

But those abstractions and their boundaries usually break down with time, and similar code starts to become spread all over.

With a large codebase, it becomes difficult to know where a change needs to be made, making it harder to fix bugs and implement new features.

Scaling

Then, come the issues with scalability. When a system needs more resources, there are two ways to scale it: horizontally, and vertically.

Vertical scaling refers to adding more resources to an existing machine, such as GPU or RAM. Horizontal scaling refers to spreading out your application on multiple machines and adding more machines to your pool of resources.

Vertical scaling can be enough but will be limited at some point, as there is a limit to how much resources a single machine can have.

Horizontal scaling is in theory infinite. On the other hand, it requires your application to be able to work when spread out on multiple machines.

Even a monolithic application could work if it's spread out on multiple machines, as long as it's stateless. But monoliths have a weakness that micro-services don't have when it comes to horizontal scaling.

As a monolith contains the whole system in a single codebase, everything must be scaled together. If you only need to scale a subset of endpoints, you have no choice but to deploy the whole system.

Microservices

Unfortunately, microservices are described in a lot of different ways.

Architecture

A succinct definition I particularly like comes from "Building Microservices" by Sam Newman:

Microservices are small, autonomous services that work together.

That's enough for a first approach but lacks details to understand microservices at a deeper level. From "Microservice Architecture", we learn microservices should share the following traits:

• Small in size

• Messaging enabled

• Bounded by contexts

• Autonomously developed

• Independently deployable

• Decentralized

• Built and released with automated processes

Now, what does that mean, in practice? In the real world, your app is split into multiple services with its own set of related functionalities (while ensuring low coupling between them).

There are, at the same time, multiple instances of the same service depending on the load to handle. They communicate asynchronously to ensure messages get delivered and avoid coupling.

Challenges

Opposite to monoliths, why is development, testing, monitoring, and deployment slower and more expensive with microservices?

New challenges appear with multiple applications. For example, managing data in separate but related databases comes with more challenges than a single, unified database.

Then, you need some sort of communication between services, usually through an event bus. Making your micro-services work together, testing them correctly, as well as deployment will be a serious headache.

In the end, you should expect development to take more time with micro-services. The increased complexity also means you need a bigger team to manage it, setting up micro-services with a single and small team is a bad idea.

Scaling

There is one primary benefit with micro-services. They can be easily deployed as you need them, and scale more efficiently.

With micro-services, you can just scale the service that needs scaling, making it possible to run it on smaller, less powerful hardware. It makes it faster and more cost-effective.

Micro-services provide other benefits compared to monoliths, such as resilience, ease of deployment, and replaceability. As a monolith contains your whole app, if one of its components fails, everything else becomes unavailable.

Also, you might have experienced how hard it can be to refactor a huge codebase, whereas the size of a micro-service is usually limited. The cost to replace a service is then much more manageable.

On large projects, with numerous teams, micro-services might even have a positive impact on productivity

Distributed Monolith

A distributed monolith is the result of splitting a monolith into multiple services, that are heavily dependent on each other, without adopting the patterns needed for distributed systems.

In practice, it's the result of splitting a monolith into separate services, but keeping them tightly coupled.

That means, they still rely heavily on each other. In this context, you lose the simplicity that comes with a monolithic architecture, but don't enjoy the benefits of independent microservices.

Don't do it!

Being lowly coupled doesn't mean you have absolutely no relationship either. For example, you might send and listen to events.

Also, you should write some integration tests, or to be more precise contract tests (if you're doing microservices well).

That means, at some point, you need information on the contracts from other services. There is some relationship going on, but it doesn't make your services tightly coupled.

If you are looking for an example projects with micro-services, you might be interested in a tic-tac-toe game and its score.

Otherwise, if you are looking for a more in-depth, and practical course on micro-services: Good news, I teach micro-services in a complete guide:

Cover photo by Crawford Jolly on Unsplash

Current state

Among the fantastic tools, there is Prisma. It works perfectly, has a great DX, documentation, and much more. I encountered a single issue when working with it, unit testing.

While they have a documentation page on unit testing, with a great introduction, their method of mocking is unsatisfactory at best.

At best, that allows you to mock, one by one, the responses for the requests you believe will be called. I think this is inefficient for a few reasons:

• It requires too much setup, on every single test.

• There is a very low level of trust in the mocks you define, as you are not sure Prisma will return the same data.

• By defining these mocks yourself, you get further away from testing your app behavior, and closer to testing implementation details.

• With new versions of Prisma, you are at risk of seeing your tests being obsolete.

Let’s look at what application we want to test, which tests to write, and then define how to write unit tests.

Application structure

My backend applications are usually split into a few layers. If we take an example with a basic ExpressJS app, it has at least 3 layers: module, controller, and service.

Each set of functionality is separated into a dedicated module, which handles routing, validation, and passes the request to the controller.

The controller is where the business logic is found, and often makes use of services.

A service provides high-level functions that make requests to the database. This is where I use ORM such as Prisma.

What should be tested

I usually have two primary types of tests when working on a backend application (and many more depending on the context!). They are unit and end-to-end tests.

I try to avoid writing e2e tests when possible, as they have limitations like being slow, expensive, and giving late feedback. I usually write unit tests for low-level functions such as middlewares.

On the other hand, I don’t test my services or controllers in complete isolation. In those cases, I feel like it’s not giving me enough value for the time it takes to write tests. Instead, I want to test my endpoint behavior as a whole.

To do it, I write my tests using a test version of my backend app. Outside dependencies, like Prisma, are mocked (in an efficient way) which allows me to simulate queries in isolation using tools like SuperTest.

In this context, I write unit tests for most use-cases. It includes validation (such as parameters), authorization (ensure you’re connected with the right access), but I also verify I receive the right response, using the mocked version of Prisma. Depending on my app, there is even more use-case.

I also end up writing e2e tests, to ensure my successful response and database-dependent errors, are the expected ones, in a real environment.

Those tests may partially overlap with my unit tests, but this time using a real database. It gives me the quick and early feedback of unit tests while having the high confidence of e2e tests.

How to write those tests

In the following examples, I expect you to understand the basics of testing. That includes Jest, which is used as part of the examples.

Middleware

Middlewares don’t need a special environment to be tested in, they can be considered just like any other function.

Only thing is, they have a defined format. For Express, they must return a function that takes a request, response, and next function. Let’s have a look at the following snippet:

import { Request, Response, NextFunction } from 'express';

type Validator = (req: Request) => boolean;

export function validator(validate: Validator) {
  return (req: Request, _res: Response, next: NextFunction) => {
    const valid = validate(req);
    if (!valid) next(new Error());
    else next();
  };
}

Validator takes a function that determines if a request is considered valid, by returning a boolean based on the received request. It returns a middleware, which will throw an error if the received request is determined as invalid.

We don't want to test implementation details for this middleware, but a real scenario. With Jest, it can be tested easily by creating a temporary server (app) object using this middleware.

Then, we can send requests in different use-case:

import supertest from 'supertest';
import express from 'express';

import { validator } from '../validator.middleware';

describe('validator', () => {
  const app = express();

  beforeAll(() => {
    const validate = validator((req) => req.query.mock === 'false');

    app.get('/', validate, (_req, res) => {
      res.status(201).send();
    });
  });

  it('Should return an error if request is invalid', () => {
    return supertest(app).get('/?mock=true').send().expect(500);
  });

  it('Should return a success otherwise', () => {
    return supertest(app).get('/?mock=false').send().expect(201);
  });
});

Endpoints (Unit)

I already explained I use SuperTest for my endpoints. I also talked about using a test version of my backend app. To be more precise, I have a few helper functions, dedicated to bootstraping my backend during tests and managing mocked data.

The following snippet is a good example of a unit test. We demonstrate how we can test an endpoint dedicated to creating an article.

We use helpers to bootstrap our app, generate the tokens needed for our use case, and send the request with SuperTest.

import { Express } from 'express';
import supertest from 'supertest';

import { ArticleFixture, ServerMock, UserMock } from '../../../../testing';

describe('POST /article', () => {
  let app: Express;
  const tokens = UserMock.generateTokens();

  beforeAll(async () => {
    app = await ServerMock.createApp();
  });

  test("Should return error if user isn't authenticated", () => {
    return supertest(app).post('/article').send(ArticleFixture.articles.newArticle).expect(401);
  });

  test("Should return error if user doesn't have ADMIN role", () => {
    return supertest(app)
      .post('/article')
      .set('Authorization', `Bearer ${tokens.user}`)
      .send(ArticleFixture.articles.newArticle)
      .expect(401);
  });

  it('Should create article', () => {
    return supertest(app)
      .post('/article')
      .set('Authorization', `Bearer ${tokens.admin}`)
      .send(ArticleFixture.articles.newArticle)
      .expect(201);
  });
});

Mocking with Prisma

But we still didn’t solve the issue that comes with Prisma. In the above snippet, it looks like nothing is mocked.

There is a single solution if we want to write tests with no dependence to a database or heavy mocking: using an in-memory implementation of Prisma.

Introducing prismock. Disclaimer: I am indeed its creator.

As there was no satisfying solution to efficiently write unit tests with Prisma, I decided to write my own solution.

It actually reads your schema.prisma and generates models based on it. It perfectly simulates Prisma’s API and store everything in-memory for fast, isolated, and retry-able unit tests.

Remember how I use a helper to build a test version of my backend app?

In production I build my app, using a genuine PrismaClient, which is then bootstrapped. During my test, I replace PrismaClient using dependency injection.

In the above snippet, it’s done as part of ServerMock.createApp(), which makes it virtually invisible when I write my tests.

Endpoints (E2E)

In a context where our article endpoint and authorization process are already tested, we could argue that it’s not mandatory to test authentication on every single endpoint during e2e tests.

For example, we could end up with the following test:

import supertest from 'supertest';

import { ArticleFixture } from '../../fixtures';
import { ArticleMock } from '../../mocks';
import E2EUtils from '../EndToEndUtils';

describe('POST /article', () => {
  let tokens: { admin: string };

  beforeAll(async () => {
    tokens = await E2EUtils.generateTokens();
  });

  it('Should return created article', async () => {
    return supertest('http://localhost')
      .post('/article')
      .set('Authorization', `Bearer ${tokens.admin}`)
      .send(ArticleFixture.articles.newArticle)
      .expect(201)
      .then((response) => {
        expect(response.body).toEqual({
          title: ArticleMock.articles.newArticle.title,
          content: ArticleMock.articles.newArticle.content,
          slug: ArticleMock.articles.newArticle.slug,
        });
      });
  });
});

This test must be written in a different environment, where we have access to a seeded database, and our endpoint has been built and runs in a near-production environment.

Conclusion

In this context, we should cover the entirety of our codebase with unit tests, giving us fast and early feedback, with a strong trust in our test results.

Using an in-memory implementation of Prisma instead of manual mocks increases our confidence even more. Together with our testing strategy (defined in what should be tested), we also end up with amazing productivity.

Finally, we write E2E tests exclusively for use-cases that make requests to our database. It does overlap with some unit tests, is slower, and more expensive with late feedback, but it eliminates the remaining grey areas.

We are then able to answer:

Are you confident in shipping your app to production?

Looking for a complete course on creating backend apps with Node.JS?

Learn everything you need on scalablebackend.

Photo by Roman Mager on Unsplash

Test types

If you are not familiar with testing, you might get a bit lost. There are a lot of test types, but some are more common.

The following article from Atlassian provides a good starting point.

As we will take our first step in the Node.js test environment, our scope will revolve around unit and integration tests.

Different tools

Now, you might be wondering about where to start. You’ve seen a Node.js project that uses Jest, heard about Mocha or Chai but you are not sure what those are about.

Great, that’s exactly what we will be discussing today. To have a clearer picture, we can separate the different kinds of tools we need.

Test runners

You have this vague idea of writing tests but how do you organize and run them? This is the role of test runners. Some of their functionalities are:

• Finding test files and running tests

• Reporting a test success or failure

• Configuring which tests to run or re-run when updated

• Setting up an environment

And a lot more.

Here is a graph comparing the most popular Node.js test runners by download:

Assertions

Now that you have an environment where you can write your tests, we come to the most important question: How do I write my first test?

From our previously cited article, Atlassian says the following about unit tests:

They consist in testing individual methods and functions of the classes, components, or modules used by your software.

From a practical perspective you can view it as the following:

• Get the result from your individual unit (function for example) in a situation (with defined parameters).

• Ensure the given result match the expected one.

That’s what assertions are about: comparing the received result with the expected one to report the test as a success or failure.

Like tests runners, there are several libraries helping you with assertions:

Spies

With unit and integration testing comes a difficulty:

• You might want to unit test a function that relies on an external dependency.

• For unit as well as integration tests, your function can have a native dependency you cannot use in a JS environment.

• Your function is making an API call but your server is not set up in your testing environment.

That’s where spies are used. They help you create fakes (or mock objects) and replace dependencies with an object you defined.

In the same way, several spy libraries can help you:

Making a choice

Great, you now have a general idea of what tools you need and a list of the most popular ones. Now comes the hardest part: which tools to choose?

Test runner

To be honest, I never really considered Jasmine, Ava, and QUnit.

I first started testing with Backend projects. At the time, Mocha was the more widely used, that’s the only reason why I started using it (with Chai).

Mocha worked great for a few years and then two changes happened:

• I started to specialize in React

• Jest started to overthrow Mocha

At this point, I had to do a serious comparison.

Mocha is a test runner that lets you choose an external assertion and spy library. It doesn’t restrict you but gives you more flexibility.

Jest is a whole testing framework, shipped with React and maintained by Facebook. From the previous sections and graphs, you might have noticed that more than a test runner, Jest includes its own assertion and mock libraries.

It’s interesting to note that Jest was built on top of Jasmine.

Both are very similar. Of course, their APIs change, and you need to get used to it when going from one to the other.

I’m a big fan of having a single library/framework/utility that fulfills a given role. After trying out Jest and experimenting with React, I definitely adopted it.

Afterward

Once you understand how to write tests, your best move would be to write great tests.

Test-Driven Development is a software development process that will definitely help you in writing great tests. Another useful tool is Code Coverage.

I would like to complete the article from Atlassian on Code Coverage by saying the following:

If your Code Coverage is below 100% you can be sure you didn’t test everything. If it’s 100% … you don’t know.

Code Coverage can tell you if your code has been executed during your tests. Sometimes, you’ll end up executing code without really testing it. To be sure that you really tested everything, you must resort to Mutation Testing.

Mutation Testing is great but really expensive, and cannot be used as much as unit/integration testing.

Once you get into testing, you often see the following pyramid:

What this represents is how many tests you should have. As unit tests are cheap to write and run, you should have plenty of them.

Still cheap but less than unit tests are: integration tests. It’s expected for an application to have a lot of integration tests but less than unit tests.

Finally, you’ll have e2e tests but in fewer numbers, as those are expensive to set up, write, and run.

Good luck on your testing journey.

Cover photo by flowforfrank on Unsplash