Microservice at a frontend level

front-endmicroservices

I'm a software developer, and the kind of developer we call "front end developer". I'm working on stuff like Angular, React, Vuejs and many others.

I wanted to know how we can organize our front end code so that we can fit a microservice architecture.

Actually, we scale services across units, each service is "independent" or at least, is decoupled from the others. This makes perfect sense. My question is:

How can we organize code, so that our front end code can matches these services?

I don't want to build monolithic applications in a microservice and big scale context. I was thinking of a way to split my front end components. But the problems come when we try to expose those components in a webpage that would aggregate them to build a real application…

I'm a bit lost in this situation and I need some help understanding the flow on a front end side.

If you can, please link any articles, or practices that could help me.

Best Answer

The last week or so I've been exhaustively researching the idea of microservice organization on the FrontEnd.

I think the easiest approach would be to leverage your library/framework of choice to separate different pieces of the Front End in verticals that correspond to the respective backend micro services. In Angular that would be something like Modules that are lazy loaded where each module corresponds to a microservice. You could go so far as to use your build tooling (ie. Webpack) to limit the output to just the components for the micro service(s) being deployed.

If you already have discrete front end repositories then it's more challenging because you have to decide how to stitch together the components. Some options for page composition include:

HTML iframes which have been around for a long time, but have trade-offs such as performance, communication between components, nesting of components, etc. However iframes offer the most freedom when it comes to allowing two (micro service) components to run side-by-side in the same DOM.
Polymer, Vue and React offer a lot when it comes to composition of custom elements but without a different root document you'll have to carefully manage component dependencies so libraries aren't fighting/breaking each other.
native web components are eventually coming to modern browsers but you'd be better off using Polymer, Vue or React as I believe they offer polyfills and other advantages.

Since I can only post 2 links, here are perhaps the most relevant.

Related Solutions

Data Security Between Users in a Microservice Architecture

There is no need to duplicate data, instead each service needs to have the proper data context.

Let's say one has users and orders. Each order at minimum is going to be tagged with a user Id that placed the order. The order data context has no idea of the relationships of users or any addition information, only the User Id is needed.

The user service would know details about the user and the relations between other users.

So, one would have two services, user and order. The user service would have a method like:

GetMyUsers(UserId)

This would return the list of users that user can "see".

Then the order service has a method like:

GetOrders(List<UserIds>)

And Potentially...

GetMyOrders(UserId)

One could have a 3rd service that could orchestrate the events if necessary, although in this case it may not be necessary since it seems sequential.

Microservices – How to Handle File Events with REST API

The best solution is to change whatever generates the files so that it sends them to your api rather than saving them to files.

This allows your api to be triggered on a new file being added and do whatever is appropriate, ie save its content and meta data to a database of some sort.

If you can't change the source of the files, then yes. A tertiary application which monitors the directory and posts the files in response to IO events is better than adding that logic to the api.

Generally speaking separation is good. Something to bear in mind when you are talking about a single "connector" api. Maybe you should be thinking about multiple apis with more specific purposes?

Best Answer

Related Solutions

Data Security Between Users in a Microservice Architecture

Microservices – How to Handle File Events with REST API

Related Topic