Most of our systems have or expose APIs that are consumed by other downstream services.

We call them REST APIs, but we actually put into practice only some of the principles that made REST a powerful architectural pattern. By doing this, we just ended up serving JSON or XML responses over HTTP.

As a consequence, we extensively use HTTP as a protocol throughout 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, 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. Exactly this is what happens here.
We will see what are the usual steps to do that, and what transformations we have to do in our arhitecture, 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.

# Workshop Structure & Contents

- Why API design matters
- How we address the NFRs
- what makes a good API
- Pub/Sub
- Commands
- Request/Response with messaging
- Dealing with errors
- Reliability
- Error Handling
- Fault tolerance
- Resilience tactics
- Outbox
- Sagas
- Routing Slips
- Observability

Prerequisite

This is a Bring Your Own Device (BYOD) workshop. Therefore, attendees are required to bring their device with the necessary software already installed:

- Need to have Visual Studio, or an IDE you are familiar with
- .NET 9 or higher
- Docker
- Github
- RabbitMQ installed as a standalone instance, or we will install it in Docker

Who should attend?

- The workshop targets .NET Software developers who want to have a more architecture-focused approach
- C# developers who want to understand the communication patterns and the best practices for APIs in distributed architectures.

**At the end of this workshop, you will be able to:**

- understand which APIs are best suited for which scenarios
- understand what are the non-functional requirements needed for production-ready APIs
- evolve a ‘traditional’ architecture to a more complex one that uses asynchronous messaging
- Understand what asynchronous messaging brings to the table and where it can benefit our distributed systems