A good friend of mine once told me about a conference talk that was about so-called task-based UIs. I considered this architecture style for an application in a private bank which was responsible for checking the suitability for finance instrument transactions.

I'm on a project with a completely different topic now. However, the software architecture and the way business entities are getting processed are quite similar. So I remembered this architectural pattern from those times. Since I consider that a very good fit, it might be worth an article.

Pipes and filters

Task-based UI is a special kind of micro frontend architecture pattern invented for a very specific use case.

Imagine we have a business entity that follows a well-defined business process during its lifetime. We can model that with the well-known pipes and filter architecture pattern.

This pattern is quite flexible. It can enforce the sequential flow of the business process. But it is not necessary. Certain process steps can also be handled in parallel.

It fits very well into a microservice architecture where every task along the business process gets handled by its own microservice. But what about the UI for such an application? We don't want to lose the benefit of the decoupling gained through the microservice architecture. I wrote a few articles about this topic. It basically leads us to go in the direction of micro frontends or self-contained systems.

We can actually go a step further and introduce an SCS per process step. Every SCS has its own UI and is responsible for handling the process step it is responsible for in its own UI.

The idea behind a task-based UI

There is actually nothing new until now. Anything I described so far we do in an SCS system as well. The idea of the task-based UI starts with the need for an overview of the entities describing their status along the process. This is not a simple thing since the processing of the entities is now distributed.

We could build an SCS gathering all the data from the process-related data over an API and build a UI that aggregates this data. This will build up a strong dependency on those SCS and this is something we actually want to avoid. We have a loose coupling through the asynchronous nature of the pipes and filter architecture and destroy it more or less with an aggregation.

What is, when we would leverage the micro frontend approach? Every SCS can provide a frontend snippet showing their piece of status from the corresponding entity. This is will return the responsibility of displaying its own data to its origin and we can loosely couple it in the frontend. This UI composition pattern is called task-based UI.

How we can implement this technically?

Task-based UI's are a special kind of micro frontends. Basically, every technical approach of the micro frontend architecture pattern also works for task-based UIs. A modern way to build micro frontends will leverage the new standard of web components. I will not explain how to build micro frontends and web components in this article. But give you a small example of how it could look like using them. Important is, that we pass in only the identifier of the processed entity. The rest is the responsibility of the corresponding microservice or SCS:

<script src="...../financial-instruments.js" />
<script src="...../suitability-check.js" />
<script src="...../document-handover.js" />
<script src="...../contact-notes.js" />

<fi-transaction-proposal>
    <financial-instruments order-id="1" />
    <suitability-check order-id="1" />
    <document-handover order-id="1" />
    <contact-notes order-id="1" />
</fi-transaction-proposal>

Summary

Entities that will go through several steps of a business process can be distributed with the pipes and filter architecture pattern. Aggregating and displaying the data from the different services/steps will break the benefits of the distributed and loosely coupled architecture. We can mitigate this problem by introducing the task-based UI architecture pattern. This is a special type of micro frontends dedicated to displaying the status(es) of entities that go through a distributed business process.

What do you think about this architectural pattern? Did you already have some experience with something similar? Leave a comment and discuss it with me.