We talk and write a lot about frontend architecture, but of course the architecture story doesn't end with service communication. Therefore, in this interview with our fullstack expert Daniel Murrmann, we also shed light on the backend side.
Manfred: With micro frontends, you want to bring the benefits of micro services to the client. How do you see the relationship between the two types of architecture?
Daniel: Completely independent from my point of view. There can also be several separate front ends for each micro service infrastructure. From this perspective, one can see that there does not necessarily have to be a connection. Sometimes there are similarities here, but there are also cases in which it makes sense to make a completely different cut in the front end with the micro front ends than in the micro services environment.
Manfred: In the course of the interaction of micro frontends and micro services, there is always talk of a backend for frontend, BFF for short. What is it and when do you use it?
Daniel: From my point of view, a backend for frontend is a butler for a (micro)frontend. It knows the needs of the frontend and is the ideal counterpart to this on the backend side. The tasks that a BFF can take on for a front end are very diverse.
An important feature of micro service architectures is the aggregation of data from multiple micro services so that a front end does not have to collect the data from many different micro services itself. This task is usually easier and better to implement with the tools that we have available on the backend side.
Other features that can be built into a BFF, which I also like to call an API gateway, are: authentication, authorization, routing to microservices, collecting telemetry data, creating hypermedia documents for real RESTful APIs.
It is important to note that 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 the issue of authentication. What are the options for authenticating with a Web API?
Daniel: The de facto standard that prevails here today are token-based authentication mechanisms, based on the OAuth 2 and OpenId Connect standards. It is still common for a client to request a token from an authorization server and then use this to authenticate at the BFF. Recently, however, the trend has been to only give the client an http-only cookie and to manage the token completely on the server side to ensure the greatest possible security.
Then the BFF gets another task, namely requesting the token itself, caching it, and then issuing a cookie to the client.
Manfred: Ok, that was the authentication. How and where does the authorization take place?
Daniel: The authorization is implemented very differently, since it also depends very much on the requirements of the overall system. There are very simple cases where it's enough for a BFF to check whether there is certain information in the token, e.g. B. whether this has write or only read rights. In other cases, the authorization must decide whether a specific operation can be performed on a specific record, depending on the user and business rules, down to a single record. Then the logic of the authorization is usually deeply rooted in the business logic.
Manfred: DDD is often mentioned in the same breath as Micro Services. What does one have to do with the other?
Daniel: Domain Driven Design is a great approach to breaking down today's complex systems into sub-problems. To do this, DDD provides us with methods and tools that we can use to work in a structured and objective manner from the (rough) requirements for a system to its cut.
In the end, so-called bounded contexts are created -- these are separate solution areas that each deal with 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 a separate microservice. Thus, DDD, which had its origins about 20 years ago, can be implemented wonderfully with today's architectural concepts.
DDD can not only help to cut an entire system, DDD can also help to develop clean WebAPI endpoints that always work on so-called aggregates defined by DDD.
Manfred: How do I get a good domain cut?
Daniel: This is actually a very challenging step when designing a new architecture/system. And above all, it's something you don't usually do every day. So there is very little practice in this activity. From my point of view, it is therefore always advisable to have architects who have experience in this activity support you in this step.
Since I'm trained as an agile coach myself, I also use many methods from the field of agile development methods, which I associate with DDD. I typically start by defining epics and personas to set a goal. This is followed by an event storming workshop. Within the event storm, I then try to identify the first cuts based on objective criteria such as the coupling of data and functions or pivotal events.
The methods from DDD are then applied. I draw a first context map and in theory we test the context map against our event storm. If something doesn't work, either the event storm or the context map is adjusted. This can be repeated a number of times. We've made it when the context map makes everyone feel good. The required bounded contexts and their interdependencies are then on the context map.
Manfred: That sounds exciting. The bound contexts often result in their own micro services. How do they communicate with each other?
Daniel: Here we have a whole range of different technologies to choose from. The most important are probably: HTTP for synchronous communication, message and event bus systems such as RabbitMQ for asynchronous communication and if it has to be very performant or larger binary data has to be transmitted, you could use gRPC.
More on this: Server week 🔥
You can find out more about topics such as ✅ Micro Services, ✅ REST APIs ✅ DDD and ✅ modern authentication in our server week, in which we "tell the end" of our story about frontend architectures in the backend:
Daniel Murrmann has been involved in software engineering as well as the architecture and implementation of complex distributed software systems in the industrial environment for years. The qualified computer scientist and certified software architect relies on Angular in the front end. Daniel was also able to gain experience at several well-known companies and was responsible for a large Industry 4.0 project at a German machine factory, which also used Angular in the front end.
