Configuring a microservice landscape, should the view be monolithic or be attached to core services?

Question

I'm migrating my monolithic web application to a microservice based one. I'm going to use Spring cloud and I've got a discovery service where all the rest of the services are registered. A simplified schema of the architecture is drawn here:

Both Equipment and Task services have their own RESTful HTTP API. They take care of which operations user can perform based in roles, which are stored in a OAuth2 token, which is delivered by a proper OAuth2 Authorization server.

Now let's talk about the clients. For the mobile native app, it will grab a token from the Authorization Server for the user. Then, core services are accessed directly with that token. If the end user tries to perform an operation which has not been granted for, it will be rejected, as security is implemented at API method level.

For browser access, we could have gone with AngularJS and access the core REST API directly, but we're a bit inexperienced on it and we've chosen to implement a third service which houses the JSF framework. The views will be rendered by JSF, so the UI-Service has to talk with core services in JSON language and parse it to java (that's a breeze using Jackson library).

The decision to make the UI service monolithic is that if we want to store some data in server session, we won't need session clustering to share it amongst more UI-Services. If we want to do horizontal scaling, we might always stick to session-in-one-instance pattern.

I've even been told not to implement the UI-service as separated at all, but to integrate it in the core services. As everything is implemented in Java, that way I should not take care of JSON parsing, but it might be coupling the UI and core part tightly.

Any suggestions about it?

Answer 1

You seem to already have a monolithic UI - the native mobile app is the UI client, and its standalone. Why then would you want to incorporate a webserver-based UI inside the core services?

The webserver UI should be considered to be another client, just like your native app, then the core services can be implemented without any consideration for any UI, they simply exist to serve whichever UI calls them, and all the UI-specific bits are nicely decoupled.

Answer 2

As defined, your 'UI Service' will have to change every time either any of the other two services changes. That's the opposite of encapsulated, and won't scale as you add more services.

And if you don't plan to scale to another few tens to hundreds of services, then you likely picked an inappropriate architecture for your system.

On that point, it is particularly worrying that you regard putting things in the same process as 'coupling'; that is one of those subtly wrong ideas that risks ending up with an un-manageable distributed monolith. Sometimes, the best way two decouple two interacting things is to put them in the same process; then they can use the native language's superior API and dependency management tools instead of relying on a simplistic REST approach.