Microservices

Contents

1. Introduction
2. Best Practices
3. Development Environment
4. Prerequisites
5. Architecture
6. Source Code
7. Microservices
   1. Catalog Microservice
   2. Identity Microservice
   3. Adding JWT to Catalog Microservice
   4. Cart Microservice
8. API Gateways
9. Client Apps
10. Unit Tests
11. Monitoring using Health Checks
12. How to Run the Application
13. How to Deploy the Application
14. References

<a id="introduction" name="introduction">Introduction</a>

A microservices architecture consists of a collection of small, independent, and loosely coupled services. Each service is self-contained, implements a single business capability, is responsible for persisting its own data, is a separate codebase, and can be deployed independently.

API gateways are entry points for clients. Instead of calling services directly, clients call the API gateway, which forwards the call to the appropriate services.

There are multiple advantages using microservices architecture:

• Developers can better understand the functionality of a service.
• Failure in one service does not impact other services.
• It's easier to manage bug fixes and feature releases.
• Services can be deployed in multiple servers to enhance performance.
• Services are easy to change and test.
• Services are easy and fast to deploy.
• Allows to choose technology that is suited for a particular functionality.

Before choosing microservices architecture, here are some challenges to consider:

• Services are simple but the entire system as a whole is more complex.
• Communication between services can be complex.
• More services equals more resources.
• Global testing can be difficult.
• Debugging can be harder.

Microservices architecture is great for large companies, but can be complicated for small companies who need to create and iterate quickly, and don't want to get into complex orchestration.

This article provides a comprehensive guide on building microservices using ASP.NET Core, constructing API gateways using Ocelot, establishing repositories using MongoDB, managing JWT in microservices, unit testing microservices using xUnit and Moq, monitoring microservices using health checks, and finally deploying microservices using Docker.

<a id="best-practises" name="best-practises">Best Practices</a>

Here's a breakdown of some best practices:

• Single Responsibility: Each microservice should have a single responsibility or purpose. This means that it should do one thing and do it well. This makes it easier to understand, develop, test, and maintain each microservice.
• Separate Data Store: Microservices should ideally have their own data storage. This can be a separate database, which is isolated from other microservices. This isolation ensures that changes or issues in one microservice's data won't affect others.
• Asynchronous Communication: Use asynchronous communication patterns, like message queues or publish-subscribe systems, to enable communication. This makes the system more resilient and decouples services from each other.
• Containerization: Use containerization technologies like Docker to package and deploy microservices. Containers provide a consistent and isolated environment for your microservices, making it easier to manage and scale them.
• Orchestration: Use container orchestration tools like Kubernetes to manage and scale your containers. Kubernetes provides features for load balancing, scaling, and monitoring, making it a great choice for orchestrating microservices.
• Build and Deploy Separation: Keep the build and deployment processes separate. This means that the build process should result in a deployable artifact, like a Docker container image, which can then be deployed in different environments without modification.
• Stateless: Microservices should be stateless as much as possible. Any necessary state should be stored in the database or an external data store. Stateless services are easier to scale and maintain.
• Micro Frontends: If you're building a web application, consider using the micro frontends approach. This involves breaking down the user interface into smaller, independently deployable components that can be developed and maintained by separate teams.

<a id="dev-env" name="dev-env">Development Environment</a>

• Visual Studio 2022 >= 17.8.0
• .NET 8.0
• MongoDB
• Postman

<a id="prerequisites" name="prerequisites">Prerequisites</a>

• C#
• ASP.NET Core
• Ocelot
• Swashbuckle
• Serilog
• JWT
• MongoDB
• xUnit
• Moq

<a id="architecture" name="architecture">Architecture</a>

There are three microservices:

• Catalog microservice: allows to manage the catalog.
• Cart microservice: allows to manage the cart.
• Identity microservice: allows to manage authentication and users.

Each microservice implements a single business capability and has its own dedicated database. This is called database-per-service pattern. This pattern allows for better separation of concerns, data isolation, and scalability. In a microservices architecture, services are designed to be small, focused, and independent, each responsible for a specific functionality. To maintain this separation, it's essential to ensure that each microservice manages its data independently. Here are other pros of this pattern:

• Data schema can be modified without impacting other microservices.
• Each microservice has its own data store, preventing accidental or unauthorized access to another service's data.
• Since each microservice and its database are separate, they can be scaled independently based on their specific needs.
• Each microservice can choose the database technology that best suits its requirements, without being bound to a single, monolithic database.
• If one of the database server is down, this will not affect to other services.

There are two API gateways, one for the frontend and one for the backend.

Below is the frontend API gateway:

• GET /catalog: retrieves catalog items.
• GET /catalog/{id}: retrieves a catalog item.
• GET /cart: retrieves cart items.
• POST /cart: adds a cart item.
• PUT /cart: updates a cart item.
• DELETE /cart: deletes a cart item.
• POST /identity/login: performs a login.
• POST /identity/register: registers a user.
• GET /identity/validate: validates a JWT token.

Below is the backend API gateway:

• GET /catalog: retrieves catalog items.
• GET /catalog/{id}: retrieves a catalog item.
• POST /catalog: creates a catalog item.
• PUT /catalog: updates a catalog item.
• DELETE /catalog/{id}: deletes a catalog item.
• PUT /cart/update-catalog-item: updates a catalog item in carts.
• DELETE /cart/delete-catalog-item: deletes catalog item references from carts.
• POST /identity/login: performs a login.
• GET /identity/validate: validates a JWT token.

Finally, there are two client apps. A frontend for accessing the store and a backend for managing the store.

The frontend allows registered users to see the available catalog items, allows to add catalog items to the cart, and remove catalog items from the cart.

Here is a screenshot of the store page in the frontend:

The backend allows admin users to see the available catalog items, allows to add new catalog items, update catalog items, and remove catalog items.

Here is a screenshot of the store page in the backend:

<a id="src" name="src">Source Code</a>

• CatalogMicroservice project contains the source code of the microservice managing the catalog.
• CartMicroservice project contains the source code of the microservice managing the cart.
• IdentityMicroservice project contains the source code of the microservice managing authentication and users.
• Middleware project contains the source code of common functionalities used by microservices.
• FrontendGateway project contains the source code of the frontend API gateway.
• BackendGateway project contains the source code of the backend API gateway.
• Frontend project contains the source code of the frontend client app.
• Backend project contains the source code of the backend client app.
• test solution folder contains unit tests of all microservices.

Microservices and gateways are developed using ASP.NET Core and C#. Client apps are developed using HTML and Vanilla JavaScript in order to focus on microservices.

<a id="microservices" name="microservices">Microservices</a>

<a id="catalog-microservice" name="catalog-microservice">Catalog Microservice</a>

Let's start with the simplest microservice, CatalogMicroservice.

CatalogMicroservice is responsible for managing the catalog.

Below is the model us