Full-Stack Architecture: An Interview with Daniel Murrmann
Frontend architecture often takes center stage in our discussions, but the architectural journey doesn't stop at service communication. In this interview, our full-stack expert Daniel Murrmann sheds light on the backend side of the equation.
Manfred: Micro frontends aim to bring the benefits of microservices to the client. How do you see the relationship between these two architectural styles?
Daniel: From my perspective, they are completely independent. Any microservice infrastructure can support multiple separate apps, micro frontends, or other clients. Just from this angle, it's clear that there isn't a mandatory connection between them. While similarities sometimes exist, there are also cases where it makes sense to draw entirely different boundaries in the frontend with micro frontends than in the microservices world.
Manfred: In discussions about combining micro frontends and microservices, a Backend for Frontend (BFF) frequently comes up. What is it, and when should you use one?
Daniel: A Backend for Frontend is, in my view, a butler for a (micro) frontend. It understands the frontend's needs and serves as the optimal counterpart on the backend side. The tasks a BFF can handle for a frontend are quite diverse.
A key feature in a microservice architecture is aggregating data from multiple microservices, so a frontend doesn't have to gather data itself from many different services. This task is typically easier and better executed with the tools available on the backend side.
Additional features you can build into a BFF—which I also like to call an API Gateway—include: authentication, authorization, routing to microservices, collecting telemetry data, and creating hypermedia documents for true RESTful APIs.
It's important to note that, in my opinion, if you want to build a single-page application, the best possible result can only be achieved with the help of a BFF.
Manfred: You mentioned authentication. What options are available for authenticating against a web API?
Daniel: The de facto standard today is token-based authentication mechanisms following the OAuth 2 and OpenID Connect standards. A common approach is for a client to request a token from an authorization server and then use it for authentication at the BFF. Recently, however, the trend is shifting back toward giving the client only an http-only cookie and managing the token entirely server-side to ensure maximum security.
This gives the BFF an additional responsibility: requesting the token itself, caching it, and then issuing a cookie to the client.
Manfred: Okay, that covers authentication. How and where does authorization take place?
Daniel: Authorization is always implemented quite differently since it heavily depends on the overall system's requirements. There are very simple cases—where a BFF just checks a token to see if it contains certain information for the current user, such as whether they have write or only read permissions. In other cases, authorization must decide down to individual data records, depending on the user and business rules, whether a specific operation on a specific record is allowed. Then, the authorization logic is typically deeply embedded within the business logic.
Manfred: Domain-Driven Design (DDD) is often mentioned alongside microservices. What do they have to do with each other?
Daniel: Domain-Driven Design is an excellent approach for breaking down today's complex systems into sub-problems. DDD provides methods and tools that help us work systematically and objectively from the (high-level) requirements of a system down to its boundaries.
What emerges are so-called bounded contexts—these are distinct solution areas, each addressing one of the sub-problems. The particularly nice thing is that, in the end, you can usually simply say that each bounded context is implemented as its own microservice. Thus, DDD—which has its origins about 20 years ago—can be wonderfully combined with today's architectural concepts.
DDD isn't only useful for slicing a whole system; it can also help develop clean web API endpoints that always operate on so-called aggregates, which are defined through DDD.
Manfred: How do I arrive at a good domain boundary?
Daniel: This is indeed a very demanding step when designing a new architecture or system. Above all, it's something you don't do every day, so you rarely get much practice at it. Therefore, I always recommend getting support from architects who have experience with this kind of work.
Since I'm also trained as an agile coach, I use many methods from agile development practices, which I combine with DDD. I typically start by defining epics and personas to establish a goal. Next comes an event storming workshop. During the event storm, I try to identify initial boundaries based on objective criteria such as the coupling of data and functions or pivotal events.
Then I apply DDD methods. I draw a first context map, and we test the context map in theory against our event storm. If something doesn't work, we adjust either the event storm or the context map. This can repeat several times. We're done when the context map feels right to everyone. At that point, the context map shows the required bounded contexts and their dependencies on each other.
Manfred: That sounds fascinating. Now, bounded contexts often result in their own microservices. How do they communicate with each other?
Daniel: There's a whole range of different technologies to choose from here. The most important ones are probably: HTTP for synchronous communication, message and event bus systems such as RabbitMQ for asynchronous communication, and when you need maximum performance or need to transfer larger binary data, you could fall back on gRPC.
More on this topic: Server Week 🔥
You can learn more about topics such as ✅ Microservices, ✅ REST APIs, ✅ DDD, and ✅ modern authentication in our Server Week, where we "finish the story" of our frontend architecture journey on the backend:
Daniel Murrmann has been working in software engineering for years, focusing on the architecture and implementation of complex distributed software systems in industrial environments. The trained computer scientist and certified software architect uses Angular on the frontend. Daniel has also gained experience at several well-known corporations and was responsible, among other things, for a large Industry 4.0 project that used Angular in the frontend at a German machinery manufacturer.
