Request-EndPoint-Response (REPR)

This chapter introduces the Request-EndPoint-Response (REPR) pattern, which we add on top of Vertical Slice Architecture and CQS. We continue to simplify our codebase to make it even more readable, maintainable, and less abstract, yet still testable.

We pronounce REPR like “reaper,” which sounds way better than “rer” or “reper.” I must credit Steve “Ardalis” Smith for this outstanding pattern name. I left a link to his article in the Further reading section.

We have leveraged this pattern already, possibly without you knowing its name. Now, it is time to formally introduce it and put a name to it, and then we assemble a technology stack to make it scalable for a real-world application.

We build that solution and then improve it during the chapter by exploring manual techniques,existing tools, and open-source libraries. The result is not perfect, but we improve this new...

The Request-EndPoint-Response (REPR) pattern

The Request-EndPoint-Response (REPR) pattern offers a simple approach, similar to what we explored in Vertical Slice Architecture, which deviates from the traditional Model-View-Controller (MVC) pattern.

As we explored in the MVC chapter, REST APIs don’t have views, so we have to distort the MVC concept to make it work. REPR is more appropriate than MVC to build REST APIs in the context of HTTP, since each URL is a way to describe how to reach an endpoint (execute an operation), not a controller.

So, with REPR, a request hits an endpoint, which fulfills the request, and then the endpoint responds to the client with the result of that operation, forming a symbiotic relationship between the request, endpoint, and response: REPR.

Simple, elegant, yet very powerful.

Goal

REPR aims to align our REST APIs to HTTP and treat the inherent request-response concept behind the web as a first-class citizen in our application...

An e-commerce application—a slice of the real-world

This section covers parts of a larger project that extends beyond the REPR pattern, where we leverage notions we learned throughout the book and add new learning bits, while keeping the scope very narrow to ensure the project does not become too big. This learning exercise brings our journey closer to the real world. On top of this, we alter this project in the next few chapters to explore different ways to organize our code and solutions.

Context: This project slightly differs from the one we used in the previous four chapters about products and stocks. We remove the inventory from the product, add a unit price, and create a barebone shopping basket as a foundation for an e-commerce application. The inventory management became so complex that we had to extract and handle it separately (not included here).

By using the REPR pattern, Minimal APIs, and what we learned with Vertical Slice Architecture, we determine that...

Summary

We delved into the Request-EndPoint-Response (REPR) design pattern and learned that REPR follows the most foundational pattern of the web. The client sends a request to an endpoint, which processes it and returns a response. The pattern focuses on designing the backend code around the endpoint, making it faster to develop, easier to find your way around the project, and more focused on features than MVC and layers.

We also took a CQS approach to the requests, making them queries or commands, and depicting all that can happen in a program: read or write states.

We explored ways to organize code around such a pattern, from implementing trivial to more complex features. We built a technology stack to create an e-commerce web application that leverages the REPR pattern and a feature-oriented design. We learned how to leverage middleware to handle exceptions globally and how the ExceptionMapper library provides us with this capability. We also used gray-box testing to cover...

Questions

Let’s take a look at a few practice questions:

1. Do we need to use the FluentValidation and ExceptionMapper libraries when implementing the REPR pattern?
2. What are the three components of the REPR pattern?
3. Does the REPR pattern dictate that we use nested classes?
4. Why do gray-box integration tests provide a high degree of confidence?
5. Name an advantage of handling exceptions using middleware.

Further reading

Here are a few links to build upon what we learned in the chapter:

• FluentValidation: https://adpg.link/xXgp
• FluentValidation.AspNetCore.Http: https://adpg.link/qsao
• ExceptionMapper: https://adpg.link/ESDb
• Mapperly: https://adpg.link/Dwcj
• MVC Controllers are Dinosaurs – Embrace API Endpoints: https://adpg.link/NGjm

Answers

1. No. REPR does not dictate how to implement it. You can create your own stack or go with a barebones ASP.NET Core Minimal API, implementing everything by hand in the project.
2. REPR consists of a request, an endpoint, and a response.
3. No. REPR does not prescribe any implementation details.
4. Gray-box integration tests provide a lot of confidence in their outcome because they test the feature almost end to end, ensuring that all the pieces are there, from the services in the IoC container to the database.
5. Handling exceptions using middleware allows for centralizing the management of exceptions, encapsulating that responsibility in a single place. It also uniformizes the output, sending the clients a response in the same format for all errors. It removes the burden of handling each exception individually, eliminating try-catch boilerplate code.

Learn more on Discord

To join the Discord community for this book – where you can share...