Microservices should control the UI

By | Mar 30, 2019

In previous articles I discussed the different ways a use case can be broken down into services. In the following article I will extend on that and show how the back-end should drive your front-end.

Every few years the UI of software application needs to be refreshed. This can be due to technology advancements or a change in the look and feel of a company’s brand. In 90% of software systems in the wild when this happens it means the application as needs to get “re-written”. Developer will label this a refactoring but the word refactoring just means we got it wrong and have to spend more time and money to do it again…

Tell us more

An application consists out of several use cases, activities that the software operator will have with the software. In microservice systems these use cases need to be encapsulated. As my title states Microservices should control the UI. There are obviously situations where this is not possible and that is when the microservices are purely functional, they provide functionality but have no insight or control into where it will be used.

I will discuss the microservice that is created for a specific use case. Often the developer creating the service will also be creating the UI.

Give us an example!

I will be using the decomposition of a use case called “Browse Events” from a previous article Volatility based decomposition for Microservices to demonstrate this. What is important to understand is that the service should handle the entire use case.

This means; The response from the service to the UI should contain ALL the information that the UI could possible need.

  • The data.
  • As well as the UI state information. What controls should be visible, what controls should be enabled. You do not want the UI to make these decisions.

In the diagram above you can see that the client will make a single call to the service.  Below is a screenshot of mock code showing what the actual implementation will look like.

Study the code

  • The entire use case is encapsulated by the service. if a variation of BrowseEvents is needed like “BrowseEventsByDate” then the service will handle it internally. The UI will just pass the request of the specified type in.
  • The UI is focused on building the UI only. All sorting or filtering of the data happens server side.
  • The back end is providing ONLY enough information to the UI to build itself. No additional data is returned. As soon as more information is returned then the UI will be tempted to start making decisions. A “IF” in the UI code is a indication that the service is bleeding business logic into the UI.
  • The number of requests to the services are controlled.

Whenever an “IF” is observed in the UI you have to ask why am I doing this…

 

Request

If a null locationId is provided it will load the events for the default location of the user.

{
"LocationId": null
}
Response

The result from BrowseEvents will be the following json.

{
"Location": {
"Label": {
"Text": "Choose your location",
"Visible": true,
"Enabled": true
},
"PossibleLocationValues": [
{
"Id": "1",
"Name": "Capetown, South Africa"
},
{
"Id": "2",
"Name": "London, England"
},
{
"Id": "3",
"Name": "Paris, France"
}
],
"Selection": {
"Enabled": true,
"Visible": true
}
},
"Events": {
"Label": {
"Text": "List of our locations",
"Visible": true,
"Enabled": true
},
"PossibleEventValues": [
{
"EventId": "100",
"EventName": "Some big musical festival in Capetown",
"EventDescription": "Some description",
"EventImageURL": "Http://www.bookevent.com/someevent1.png"
},
{
"EventId": "100",
"EventName": "Some small musical festival in Capetown",
"EventDescription": "Some description",
"EventImageURL": "Http://www.bookevent.com/someevent2.png"
}
]
},
"BookingButton": {
"Text": "Make a booking",
"Visible": true,
"Enabled": true
}
}

2
Leave a Reply

avatar
2 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
0 Comment authors
Recent comment authors

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
newest oldest most voted
Notify of
trackback

[…] Volatility based decomposition is much harder to do and takes time to decompose and implement but the result is an application that is stable and handles the changes in requirements with ease. In the next article I will continue and show how this design allow the Microservices to control the UI. […]

trackback

[…] Functional decomposition does have its place in simple once off application but for any larger applications a different decomposition should be considered. In the next article I will continue and show how Microservices could be design to control the UI. […]