Command Query Responsibility Segregation (CQRS) applies the Command Query Separation (CQS) principle. Compared to what we saw in Chapter 14, Mediator and CQRS Design Patterns, we can push CQRS further using microservices or serverless computing. Instead of simply creating a clear separation between commands and queries, we can divide them even more using multiple microservices and data sources.CQS is a principle stating that a method should either return data or mutate data, but not both. On the other hand, CQRS suggests using one model to read the data and one model to mutate the data.Serverless computing is a cloud execution…
-
-
In this section, we learned about using the Backend for Frontend (BFF) design pattern to front a micro e-commerce web application. We discussed layering APIs and the advantages and disadvantages of a two-layer design. We autogenerated strongly typed HTTP clients using Refit, managed a shopping cart, and fetched the catalog from the BFF. We learned how to use a BFF to reduce complexity by moving domain logic from the frontend to the backend by implementing multiple Gateway patterns.Here are a few benefits that we explored: Despite these benefits, using a BFF may also increase complexity and introduce potential performance overhead.…
-
One of the primary goals of our BFF is to reduce the frontend’s complexity. When examining the Baskets service, we realized it would add a bit of avoidable complexity if we were only to serve the raw operation, so instead, we decided to encapsulate all of the shopping cart logic behind a single endpoint. When a client POST to the api/cart endpoint, it: With this endpoint, the clients don’t have to worry about adding or updating. Here’s a simplified sequence diagram that represents this logic: Figure 19.29: A sequence diagram that displays the high-level algorithm of the cart endpoint. As…
-
The BFF service must communicate to the Baskets and Products services. The services are REST APIs, so we must leverage HTTP. We could leverage the out-of-the-box ASP.NET Core HttpClient class and IHttpClientFactory interface, then send raw HTTP requests to the downstream APIs. On the other hand, we could also create a typed client, which translates the HTTP calls to simple method calls with evocative names. We are exploring the second option, encapsulating the HTTP calls inside the typed clients.The concept is simple: we create one interface per service and translate its operation into methods. Each interface revolves around a service.…
-
Now that we set up HTTPS, we can build the container using the following commands: docker compose build We can execute the following command to start the containers: docker compose up This should start the containers and feed you an aggregated log with a color per service. The beginning of the log trail should look like this: [+] Running 3/0 ✔ Container c19-repr.products-1 Created 0.0s ✔ Container c19-repr.baskets-1 Created 0.0s ✔ Container c19-repr.bff-1 Created 0.0sAttaching to c19-repr.baskets-1, c19-repr.bff-1, c19-repr.products-1c19-repr.baskets-1 | info: Microsoft.Hosting.Lifetime[14]c19-repr.baskets-1 | Now listening on: http://[::]:80c19-repr.baskets-1 | info: Microsoft.Hosting.Lifetime[14]c19-repr.baskets-1 | Now listening on: https://[::]:443… To stop the services, press Ctrl+C. When you…
-
Let’s start by exploring the deployment topology. First, we split the Chapter 18 REPR project into two services: Baskets and Products. Then, we add a BFF API that fronts the two services to simplify using the system. We do not have a UI per se, but one http file per project exists to simulate HTTP requests. Here’s a diagram that represents the relationship between the different services: Figure 19.25: a diagram that represents the deployment topology and relationship between the different services The easiest and most extendable way to start the projects is to use Docker, but it is optional;…
-
This project leverages the Backend for Frontend (BFF) design pattern to reduce the complexity of using the low-level API of the REPR project we created in Chapter 18. The BFF endpoints act as several types of gateway we explore.This design makes two layers of API, so let’s start here. Layering APIs From a high-level architecture perspective, we can leverage multiple layers of APIs to group different levels of operation granularity. For example, in this case, we have two layers: Here’s a diagram that represents this concept (high-level APIs are BFFs in this case, but the design could be nuanced): Figure…
-
A gateway is a façade that shields or simplifies access to one or more other services. In this section, we explored the following: We can use any microservices pattern, including gateways, and like any other pattern, we can mix and match them. Just consider the advantages, but also the drawbacks, that they bring to the table. If you can live with them, you’ve got your solution.Gateways often become the single point of failure of the system, so that is a point to consider. On the other hand, a gateway can have multiple instances running simultaneously behind a load balancer. Moreover,…
-
The Publish-Subscribe pattern uses events to break tight coupling between parts of an application. In a microservices architecture, we can use a message broker and integration events to allow microservices to talk to each other indirectly. The different pieces are now coupled with the data contract representing the event (its schema) instead of each other, leading to a potential gain in flexibility. One risk of this type of architecture is breaking events’ consumers by publishing breaking changes in the event’s format without letting them know or without having events versioning in place so they can adapt to the changes. Therefore,…
-
Let’s explore an example of what could happen if we combine what we just studied. Context: We need to build a program that manages IoT devices. We begin by creating two microservices: As a visual reference, the final system could look as follows (we cover the DeviceLocation microservice later): Figure 19.8: Three microservices communicating using the Publish-Subscribe pattern Here are the user interactions and the published events: { “id”: “some id”, “name”: “Device 1”, “other”: “properties go here…”} In parallel, the Networking microservice must know when a device is created, so it subscribed to the DeviceTwinCreated event. When a new…