Problem Description: We have a big monolith app containing UI components A,B,C,D. You can think of a component as a page for now. Component A & B share a sub-component called SHARED. Now both A & B are planing to move out of the big monolith app. The challenge here is to have same look and feel for sub-component SHARED in both A & B at all times.

My Solution: Publish the sub-component as module. Both A & B import it and use it. The problem here is whenever a new version of sub-component gets published, both A & B would need a release. Releasing both A & B at the same time won't be straight forward. This needs co-ordination between the teams that maintain A & B respectively. There may be a possibility when A got released but B had to rollback because of some other breaking change. This scenario violates our requirement of consistent look and feel for the sub-component across A & B at all times. There would be other similar scenarios too. How should we handle this?

Is there a better way to handle this situation?

  • 1
    TL;DR: Are you really thinking about this the right way? It sounds to me like your module SHARED is not really modularized. If it truly was then breaking changes would be an extremely rare occurrence. Breaking changes would also typically be a major release (i.e. version 1.2.4 to version 2.0.0) which means that both teams are expected to put in the work to verify the solution. Also, if you've modularized SHARED then you should be using a package management system to distribute it and manage versions, making it a package update, not a full release of an entire application. – Robzor Jul 26 '17 at 6:33
  • It's a web app. Packages would be node modules. Upgrading SHARED node module would require deployment. – user2899951 Jul 26 '17 at 6:37
  • I fail to see the relevance of this fact. – Robzor Jul 26 '17 at 6:54
  • So SHARED ends up being a service as well. Problem solved – Thomas Junk Jul 26 '17 at 12:43
  • 1
    @ThomasJunk This is what I'm also thinking. SHARED service response would be a independent js/html bundle which can be consumed by both A & B. By independent I mean, independent of the frameworks used by A & B. – user2899951 Jul 27 '17 at 8:48

hi wont it be better if in place of integrating the subcomponent both A & B refer it as a seprate component C? I mean structural integrity so and A and B rather than processing data from C the processing is done in C itself this will make C changes independent of both A & B and as long as we have dependency we cant make sure both A & B will be at same level /

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.