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 Backend for Frontend (BFF) pattern is yet another variation of the Gateway pattern. With Backend for Frontend, instead of building a general-purpose gateway, we build a gateway per user interface (for each application that interacts with the system), lowering the complexity. Moreover, it allows for fine-grained control of what endpoints are exposed. It removes the chances of app B breaking when changes are made to app A. Many optimizations can come out of this pattern, such as sending only the data that’s required for each call instead of sending data that only a few applications are using, saving some…
-
Another role we can give to a gateway is aggregating requests to hide complexity from its consumers. Aggregating multiple requests into one makes it easier for consumers of a microservices system to interact with it; clients need to know about one endpoint instead of multiple. Moreover, it moves the chattiness from the client to the gateway, which is closer to the microservices, lowering the many calls’ latency, and thus making the request-response cycle faster.Continuing with our previous example, we have two UI applications that contain a feature to show a device’s location on a map before identifying it using its…
-
We can use this pattern to hide the complexity of our system by having the gateway route requests to the appropriate services.For example, let’s say we have two microservices: one that holds our device data and another that manages device locations. We want to show the latest known location of a specific device (id=102) and display its name and model.To achieve that, a user requests the web page, and then the web page calls two services (see the following diagram). The DeviceTwin microservice is accessible from service1.domain.com, and the Location microservice is accessible from service2.domain.com. From there, the web application…
-
When building a microservices-oriented system, the number of services grows with the number of features; the bigger the system, the more microservices you have.When you think about a user interface that has to interact with such a system, this can become tedious, complex, and inefficient (dev-wise and speed-wise). Gateways can help us achieve the following: A gateway can also centralize different processes, such as logging and caching requests, authenticating and authorizing users and clients, enforcing request rate limits, and other similar policies.You can see gateways as façades, but instead of being a class in a program, it is a program…
-
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,…
-
The following diagram demonstrates this: Figure 19.12: The DeviceLocation microservice replaying the DeviceTwinCreated event to create its materialized view of the device twin { “device”: { “id”: “some id”, “name”: “Device 1” }, “networking”: { “type”: “MQTT” }, “location”: {…}} The following diagram demonstrates this: Figure 19.13: The DeviceLocation microservice replaying the NetworkingInfoUpdated event to update its materialized view of the device twin { “device”: { “id”: “some id”, “name”: “Kitchen Thermostat” }, “networking”: { “type”: “MQTT” }, “location”: {…}} The following diagram demonstrates this: Figure 19.14: The DeviceLocation microservice replaying the DeviceTwinUpdated event to update its materialized view of…
-
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…
-
Now that we have explored the Publish-Subscribe pattern, learned what an event is, and talked about event brokers, it is time to explore how to replay the state of an application. To achieve this, we can follow the event sourcing pattern.The idea behind event sourcing is to store a chronological list of events instead of a single entity, where that collection of events becomes the source of truth. That way, every single operation is saved in the right order, helping with concurrency. Moreover, we could replay all of these events to generate an object’s current state in a new application,…