Why microservices? That could be a sign for you, when you have a big enterprise application where you can easily by domain accessory. There’re a bunch of apps in nowadays e.g. _Google Driv_e, , etc and it’s quite obvious that and should not be a single app just because both use and same frameworks. divide logic Google Google Docs Gmail Google Drive Google Docs authentication Your case might not be so obvious as Google’s one but let me describe some of front-end microservices architecture: Benefits . You can easily divide your resources into different teams which will grow their knowledge in particular domain related to some part of the application. Maintainability . If you like to try or another new , go ahead! Not much risk, you just start one single microservice instead of rewriting everything. Technologies freedom VueJS technology . It gives so much freedom when you can release small pieces of the application. Fixes and releases go more smoothly. Independent Deployment Of course, it goes with some : Costs You need to invest time to make your apps work together. Maintaining consistency. I found more bugs once I’ve rewritten application to microservices model, which were invisible while the application was a monolith. All magic with regular deploys must work like a charm, otherwise, you will get more pains than benefits. Operational Complexity. Approach I did a research. And even asked the community for any existing examples: ? How to embed AngularJS app into another one separately deployed Is there a way to run angularJS app as polymer component? P.S. I was looking for any solutions besides iFrame. I have successfully built with as a nested component. somewhere on forums, there was a restriction about doing that. So I decided to go lower level and built the same approach on the level of Polymer AngularJS But, Web Components. solution Web Components Solution relies deeply on the single feature from Web Components standard. : a way to include and reuse HTML documents via other HTML documents ( , ). HTML Imports spec tutorial Idea is to predefine components as HTML imports, while each of them could include their own scripts and styles. So we can decide on the which HTML import should be presented in DOM at the moment, and rest of things should be handled by the imported document itself. top level HTML imports driven microservices is a top level wrapper which consists of component picker and container for components. Also should include views or controllers which allow user manipulating components. Shell — — the actual root place where HTML of nested application should be injected. (It should have a entry point for all nested apps). Container single —service which allows managing nested application which is active at the moment. Component picker — our abstract microservices. Could be whole apps written in different frameworks. HTML imports Base example of implementation Here is a with nested AngularJS and React applications. to for the support on the early phase! full repo of Web Components driven microservices Many thanks Andrew Dacenko index.html 16 LOC: for nested applications. Container Two nested applications — and . By clicking on one of two buttons we load corresponding application with the help of . angular-app.html react-app.html loader.js loader.js is a kind of which I’ve described in the previous paragraph. loader.js Component picker Conclusion This approach was implemented for a production application. It was proven by of users. thousands I would suggest to answer yourself few questions before you start dividing your application to front-end microservices: How big is your application in terms of and code? team Can you divide your app into small pieces by ? domain accessory How easy can you small features for your application? release If you want to get an info straight from the horse’s mouth follow me on and account. Twitter Medium
