An introduction into task based UI's
A good friend of mine once told me about a conference talk that was about so-called task-based UI's. I considered this architecture style for an application in a private bank which was responsible to check the suitability for finance instrument transactions.
I'm in a project with a completely different topic now. But the software architecture and the way business entities are getting processed is quite similar. So I remembered this architecture pattern from those times. Since I consider that a very good fit, it might be worth an article.
Pipes and filters
Task based UI's is a special kind of micro frontend architecture pattern invented for a very specific use case.
Imagine we have a business entity which 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 micro service architecture where every task along the business process gets handled by its own micro service. But what about the UI for such an application? We don't want to loose our benefit of the decoupling gained through the micro service architecture. I already wrote a few articles about this topic. It basically leads us to go into 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 to handle 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 of the overview for 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 which aggregates this data. This will build up a strong dependency to 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 UI's. A modern way to build micro frontends will leverage the new standard of the web components. I will not explain how to build micro frontends and web components in this article.But give you a small example 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 micro service 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>
Entities which will go through several steps of a business process can be distributed with the pipes and filters architecture patter. 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 display the status(es) of entities which go through a distributed business process.
What do you think about this architecture pattern? Did you already make some experience with something similar? Leave a comment and discuss it with me.