CODEWITHSUNDEEP
architecturefrontendsingle-page-applicationmicroservicesorchestration
wertigom
wertigom

Reputation: 313

How to manage common frontend components on microservices

How to manage frontend on microservices, especially when you have common components? I found a few solutions on the internet but all of them have some drawbacks and none of them is a good fit for us.

Let me clearify my problem. We have over 5 groups of people working on different microservices in a large single project. And almost all of them has some common,shared components on frontend. And these components are huge as they are already a different project but totally shared. Now how to manage these shared components or should we duplicate them?

First solution I found is to make those components shared and maintain from a single point like node packages and npm install when needed from different groups. But at this point the microservice approach is broken since everybody will be dependent to these components and no one will be able to maintain as soon as they need, not good. And very hard to maintain since in the future different groups may different needs from the component.

Second is to duplicate the components according to each project and develop within the microservice group but this time it becomes very frankenstein and the common concepts that we should obey are hard to catch. It's a really enterprise project that all components should match in terms of behaivor and look to the other components reoccured in the project.

So we need a frontend solution for microservices that should be suitable for an enterprise project which is needed to obey same rules(like font size,color,actions etc..) at different points as it is monolithly written, but maintainable by different groups at the same time.

How can we balance that or can we?

Thanks to @kayess: Shortly how to apply shared kernel on microservices as the teams will not be dependent to each other?

Upvotes: 3

Views: 894

Answers (1)

Vladislav Rastrusny
Vladislav Rastrusny

Reputation: 30013

First solution I found is to make those components shared and maintain from a single point like node packages and npm install when needed from different groups. But at this point the microservice approach is broken since everybody will be dependent to these components

I believe your understanding of a microservice is wrong. Fowler's definition of a microservice:

In short, the microservice architectural style 1 is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

It's ok for microservices in your company to have common components. Microservices are much higher level of abstraction, than a component. Do not try to make every component a microservice.

You should manage your components in separate repository each. Use semantic versioning to publish updates and watch over compatibility breaks.

And very hard to maintain since in the future different groups may different needs from the component.

I do not believe this is hard to maintain. The maintainability of your configuration is certainly not higher, than that of any framework around since millions of programmers depend on those frameworks and develop them together. It's a quesion of maintainer's skill.

You can go with a monolithic repository approach (put all the components into a single, but standalone repo), but I think this will mess up things pretty quickly.

Upvotes: 2

Related Questions