Most of our systems have or expose APIs that are consumed by other downstream services.
We call them REST APIs, but we actually put in practice only some of the principles that made REST a powerful architectural pattern. By doing this, we just ended up to serving JSON or XML responses over HTTP.
As a consequence, we extensively use HTTP as a protocol throught our systems, without considering its limitations.
Even though we might leverage syntactic sugar like async/await when we implement communication between our system’s components, HTTP protocol has a synchronous nature.
This limits our options when it comes to choosing a communication pattern or introducing very important quality attributes like resiliency, fault tolerance, scalability or temporal decoupling.
We overlook some of these architectural aspects until is too late, and we learn the hard way that we need them.
In this workshop, we will start with a ‘traditional’ RESTful API and make the necessary changes to introduce asynchronous messaging, all with an eye on non-functional requirements.
This is a hands-on workshop, so be prepared to write code!
By the end of the workshop, you will know how to evolve your architecture from simple to complex, from RESTful to messaging-based, that has all the extra aspects that messaging brings.
Introducing asynchronous messaging in a system is not an easy task. Sometimes, we have to unlearn what it means to do a simple Request/Response using HTTP so we can progress.
We will see what are the usual steps to do that, and what transformations we have to do in our architecture, to accommodate this.
We will deep dive into a new world that covers queues, topics, message brokers, different abstractions, and patterns like outboxes or sagas specific to distributed systems.
Prerequisite
This is a Bring Your Own Device (BYOD) workshop. Therefore, attendees are required to bring their own device with the necessary software already installed:
Who should attend?
At the end of this workshop you will be able to: