Should a State Machine or Processing Engine be abstracted away from the UI?

Question

I'm working on a suite of micro-services, with a web-based GUI. We are using a 3rd party state machine via REST calls. Sometimes we get/set state from one of our micro-services, while other times we go straight from the GUI directly to the state machine bypassing our micro-services entirely.

I'm of the opinion that the UI shouldn't do this for a few reasons:

• I prefer GUIs to be dumb; having no knowledge of components such as database, state machine, caching, etc
• I believe the GUI is merely one component of the application, not the application itself.
• I believe micro-services should be able to work independently without a hard requirement on the UI

Some counter-arguments against this have been:

• Proxying a REST call through a micro-service adds complexity to the micro-service
• It is quicker and more efficient to call straight from the UI
• Our calls to micro-services also use REST, so there is no difference in the tooling

I would like to know if there are any best-practice recommendations?

Answer 1

I've worked with UI for many years, and my experience says that you should always abstract as much program functionality away from the UI as you possibly can.

UI's are complicated enough to reason about on their own. Embedding any sort of logic in them that is not directly UI related eventually leads to an unmaintainable application that doesn't allow for any code reuse. In other words, a Big Ball of Mud.

On the other hand, having a singular focus on the UI generally produces better UI (and better program logic, which you will focus on separately).

All that said, it's impossible to create a UI that has zero knowledge of your underlying system. My advice is to sequester that knowledge in View Models.