When designing a large scale business application often times the problem ends up in the UI.  The services are properly broken up as micro services but the UI ends up being cluttered and has a monolithic feel.  For example consider a trading system. A part of the business is dedicated to design financial instruments, another part to update the pricing information, one to handle trading and clearing operation and finally the end customer who is actually buying the product.  Although my example is of a trading system, but it can very well be replaced by any system that has multiple features to a business work flow.

Recently, I was tasked to design a trading system.  After careful analysis, I came up with about 20-30 different services to handle various features.  Each service exposed a REST endpoint and an Angular module basically wrapping WebApi for simpler access.  The UI can be designed using the methods below:

Approach 1

The web application was designed to have various static HTML pages each having a link from the main Index.html.  There was one angular module to drive all the pages – the angular app.  The script for the app was loaded in each html page.  All the supporting services and modules were packaged as independent scripts and were loaded with their respective pages.  I think this approach is alright for medium scale application.  Although this doesn’t truly solve the problem of monolithic UI, it attempts to break it down in smaller subsets.  If your app starts to grow, you will quickly realize that this is a maintenance nightmare.

Approach 2

Instead of breaking down into static applications, it sometimes is quite easier to break down the entire application.  The users would have to navigate to two different websites with their own independent authentication.  This simplifies the problem of deployment and turns the UI into a service.  The authentication is handled using single sign on and the transition between apps is seamless.

Approach 3

Instead of building out a separate UI service that holds all the code and logic to display the contents or having separate UI services, it sometimes is easier to push the responsibility of UI on the core services.  Each service along with exposing a module to describing ways to perform action, it should also expose a directive that builds the necessary UI components.  Finally the composing UI service will compose components from different service and show the composite UI to the user.  With this approach there is a lot of overhead to build the UI components, but it scales very well.  A down side is the data that needs to surface to the user could be coming from multiple service – that means the composite UI service will still have to be build its contents.  This also doesn’t quite solve the problem of loading all the script.

I feel in large business application while breaking down the services, its quite possible to break down the UI into various independent deployable services and thereby applying approach 2.  If you have more suggestions, please comment.