The main idea of creating this project is implementing an infrastructure for up and running distributed system with the latest technology and architecture like Vertical Slice Architecture, Event Driven Architecture, CQRS, Postgres, RabbitMq and Express in Node.Js, and we will not deal mainly with business. 🚀
- The Goals of This Project
- Plan
- Technologies - Libraries
- The Domain and Bounded Context - Service Boundary
- Structure of Project
- How to Run
- Support
- Contribution
- ❇️ Using
Vertical Slice Architecture
forarchitecture
level. - ❇️ Using
Rabbitmq
on top ofamqp
forEvent Driven Architecture
between our microservices. - ❇️ Using
Data Centric
Architecture based on CRUD in all Services. - ❇️ Using
Rest
forinternal communication
between our microservices withaxios
. - ❇️ Using
CQRS
implementation withMediatrJs
internal library. - ❇️ Using
Express
forweb framework
. - ❇️ Using
Postgres
for database level withtypeorm
. - ❇️ Using
tsyringe
for handlingdependency injection
. - ❇️ Using
Passport
forauthentication
andauthorization
, base onJWT
. - ❇️ Using
OpenTelemetry
for distributed tracing top ofJaeger
andZipkin
. - ❇️ Using
OpenTelemetry
for monitoring top ofPrometteuse
andGrafana
. - ❇️ Using
Joi
forvalidation
input in our handlers and endpoints. - ❇️ Using
dotenv
forconfiguration
management. - ❇️ Using
Unit Testing
for testingsmall units
andmocking
our dependencies withJest
. - ❇️ Using
End-To-End Testing
andIntegration Testing
for testingfeatures
with all dependencies withtestcontainers
. - ❇️ Using
winston
and 'morgan' forlogging
. - ❇️ Using
swagger-ui-express
andtsoa
for generateapi documentation
automaticly. - ❇️ Using
ts-mapper
formapping
our objects. - ❇️ Using
Problem Details
standard forreadable details of errors
. - ❇️ Using
eslint
andprettier
forformatting
of our code. - ❇️ Using
Docker-Compose
for ourdeployment
mechanism.
🌀This project is a work in progress, new features will be added over time.🌀
I will try to register future goals and additions in the Issues section of this repository.
High-level plan is represented in the table
Feature | Status |
---|---|
Identity Service | Completed ✔️ |
Flight Service | Completed ✔️ |
Passenger Service | Completed ✔️ |
Booking Service | Completed ✔️ |
Building Blocks | Completed ✔️ |
- ✔️
microsoft/TypeScript
- TypeScript is a language for application-scale JavaScript. - ✔️
expressjs/express
- Fast, unopinionated, minimalist web framework for Node.js - ✔️
typeorm/typeorm
- TypeORM is highly influenced by other ORMs, such as Hibernate, Doctrine and Entity Framework - ✔️
amqp-node/amqplib
- A library for making AMQP 0-9-1 clients for Node.JS - ✔️
microsoft/tsyringe
- A lightweight dependency injection container for TypeScript/JavaScript for constructor injection - ✔️
open-telemetry/opentelemetry-js
- A framework for collecting traces, metrics, and logs from applications - ✔️
siimon/prom-client
- A prometheus client for Node.js that supports histogram, summaries, gauges and counters - ✔️
scottie1984/swagger-ui-express
- Serve auto-generated swagger-ui generated API docs from express - ✔️
lukeautry/tsoa
- OpenAPI-compliant REST APIs using TypeScript and Node - ✔️
axios/axios
- Promise based HTTP client for the browser and node.js - ✔️
motdotla/dotenv
- Dotenv is a zero-dependency module that loads environment variables from a .env - ✔️
PDMLab/http-problem-details
- This library implements HTTP Problem details (RFC 7807) for HTTP APIs - ✔️
helmetjs/helmet
- Helmet helps secure Express apps by setting HTTP response headers - ✔️
hapijs/joi
- The most powerful schema description language and data validator for JavaScript - ✔️
expressjs/morgan
- HTTP request logger middleware for node.js - ✔️
winstonjs/winston
- A logger for just about everything - ✔️
jestjs/jest
- A javascript framework for testing - ✔️
testcontainers/testcontainers-node
- A library to support tests with throwaway instances of Docker containers - ✔️
faker-js/faker
- Generate massive amounts of fake (but realistic) data for testing and development - ✔️
florinn/typemoq
- Simple mocking library for JavaScript targeting TypeScript development - ✔️
ladjs/supertest
- High-level abstraction for testing HTTP - ✔️
eslint/eslint
- ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code - ✔️
prettier/prettier
- Opinionated Code Formatter - ✔️
vercel/async-retry
- Retrying made simple, easy, and async
-
Identity Service
: The Identity Service is a bounded context for the authentication and authorization of users using passport. This service is responsible for creating new users and their corresponding roles and permissions using Jwt for authentication and authorization. -
Flight Service
: The Flight Service is a bounded contextCRUD
service to handle flight related operations. -
Passenger Service
: The Passenger Service is a bounded context for managing passenger information, tracking activities and subscribing to get notification for out of stock products. -
Booking Service
: The Booking Service is a bounded context for managing all operation related to booking ticket.
In this project I used a mix of clean architecture, vertical slice architecture and I used feature folder structure to structure my files.
Each microservice has its dependencies such as databases, files etc. Each microservice is decoupled from other microservices and developed and deployed separately. Microservices talk to each other with Rest or gRPC for synchronous calls and use RabbitMq or Kafka for asynchronous calls.
We have a separate microservice Identity
for authentication and authorization of each request. Once signed-in users are issued a JWT token. This token is used by other microservices to validate the user, read claims and allow access to authorized/role specific endpoints.
I used RabbitMQ as my MessageBroker for async communication between microservices using the eventual consistency mechanism. Each microservice uses amqp to interface with RabbitMQ providing, messaging, availability, reliability, etc.
Microservices are event based
which means they can publish and/or subscribe to any events occurring in the setup. By using this approach for communicating between services, each microservice does not need to know about the other services or handle errors occurred in other microservices.
I treat each request as a distinct use case or slice, encapsulating and grouping all concerns from front-end to back.
When adding or changing a feature in an application in n-tire architecture, we are typically touching many "layers" in an application. We are changing the user interface, adding fields to models, modifying validation, and so on. Instead of coupling across a layer, we couple vertically along a slice. We minimize coupling
between slices
, and maximize coupling
in a slice
.
With this approach, each of our vertical slices can decide for itself how to best fulfill the request. New features only add code, we're not changing shared code and worrying about side effects.
Instead of grouping related action methods in one controller, as found in traditional ASP.net controllers, I used the REPR pattern. Each action gets its own small endpoint, consisting of a route, the action, and an IMediator
instance (see MediatR). The request is passed to the IMediator
instance, routed through a Mediatr pipeline
where custom middleware can log, validate and intercept requests. The request is then handled by a request specific IRequestHandler
which performs business logic before returning the result.
The use of the mediator pattern in my controllers creates clean and thin controllers. By separating action logic into individual handlers we support the Single Responsibility Principle and Don't Repeat Yourself principles, this is because traditional controllers tend to become bloated with large action methods and several injected Services
only being used by a few methods.
I used CQRS to decompose my features into small parts that makes our application:
- Maximize performance, scalability and simplicity.
- Easy to maintain and add features to. Changes only affect one command or query, avoiding breaking changes or creating side effects.
- It gives us better separation of concerns and cross-cutting concern (with help of mediatr behavior pipelines), instead of bloated service classes doing many things.
Using the CQRS pattern, we cut each business functionality into vertical slices, for each of these slices we group classes (see technical folders structure) specific to that feature together (command, handlers, infrastructure, repository, controllers, etc). In our CQRS pattern each command/query handler is a separate slice. This is where you can reduce coupling between layers. Each handler can be a separated code unit, even copy/pasted. Thanks to that, we can tune down the specific method to not follow general conventions (e.g. use custom SQL query or even different storage). In a traditional layered architecture, when we change the core generic mechanism in one layer, it can impact all methods.
Run our infrastructure with docker using the infrastructure.yaml file with the below command at the root of app:
docker-compose -f ./deployments/docker-compose/infrastructure.yaml up -d
I will add docker-compsoe
for up and running whole app here in the next...
Each microservice uses swagger open api, navigate to /swagger for a list of every endpoint. For testing apis I used the REST Client plugin for VS Code running this file booking.rest.
If you like my work, feel free to:
- ⭐ this repository. And we will be happy together :)
Thanks a bunch for supporting me!
Thanks to all contributors, you're awesome and this wouldn't be possible without you! The goal is to build a categorized, community-driven collection of very well-known resources.
Please follow this contribution guideline to submit a pull request or create the issue.
- https://github.com/jbogard/ContosoUniversityDotNetCore-Pages
- https://github.com/kgrzybek/modular-monolith-with-ddd
This project is made available under the MIT license. See LICENSE for details.