Angular microservices, loadChildren from url

Question

I recently started thinking of how to effectively implement Angular in a microservices architecture.

Let's say we have a service for login, a service for user management and a service for browsing, adding and editing certain media. Each service has its own backend and frontend served in its own private container. So each part is then isolated with a clearly defined API to interact with for the backend, and its own isolated user interface consuming this API.

Now, let's say I would like to tie up each of these microservices into a single application. I have two ways (as far as I can see) to do this:

1. I can configure a server to place each service under a sub-url, and have the application be an array of SPA's, a sort of MPA (Multi Page App).

2. I can create a master app where I set up the routes for each of my micro-apps and load them on demand (custom PreloadingStrategy, I'm looking at you).

3. ^{I also found this, a process which I personally don't think highly of, because you'll lose many of the benefits of microservices in a continuous delivery scheme of things. This aims to create a SPA monolith out of microservices.}

Now, the first alternative seems like a chore, and no fun at all. The second is intriguing to me. I came accross this article: https://coryrylan.com/blog/custom-preloading-and-lazy-loading-strategies-with-angular and immediately started thinking; how can I exploit this to load pre-built angular modules from a url instead of packaging them from the file system?

So my question is; has anybody done this before? Is it possible? Are there security issues in doing this? Or are there other alternatives of tying up my microservices into a larger application?

Answer 1

Microservices shouldn't be a goal itself, it's an approach to achieve something. So, you need to answer the question what goals do you want to achieve?

One reason why people start using microservices in front-end is scalability. If your application is big enough and many teams work with one frontend it's better to use microservices in order to reduce dependencies between teams, making development more efficient - every team can develop its part independently. For instance Microsoft Azure Portal is a good example for this. It has a lot of frontend code and many teams work simultaneously on it.

But important thing here is deployment. Mostly frontend is deployed as one component, frontend microservices are not fully microservices according to classic definition. Consider looking at Angular 2 modules. Often people use microservice term in frontend as a module actually, not dedicated component which can be developed and deployed separately.

If your application is small enough (3-4 devs) and apparently won't grow to a few dedicated frontend teams then there's no point of using microservices in frontend at all adding additional complexity.

Your first option can be used when isolation between frontend parts are huge, there's no interaction between them. For instance you have a few applications which should look for user as one having the same style, components and single sign-on but these applications are totally different. Then it's better to locate them in different urls, different services (perhaps even with separate deployment) sharing common styles and components between them. That's easier to implement.

A master application can be used when parts are tied to each other and it's really one frontend application. But this approach is harder to implement and requires more interaction between teams.

The third approach takes also place as described in mentioned post.