We have 3 development teams, each team has at least one Ember app. There are more than 8 ember app in total. Each app has its own release cycle.
The problem is we have common components such as header, menu, login component. All of them have to display the same component. If we place these components in an addon, the changes of these components will be applied to apps at different times (because of different release times).
So, how can we manage this common components? Is embedding multiple apps in our base app solve this problem?
The following image can give a hint about our applications’ current layout.
If I understand this 3 teams run ember deploy to the same destination. Embedding multiple apps in your base app can perhaps be solved by using semver for all team ember addons. Each team will have to increase there ember addon’s version if they deploy the app. Perhaps use https://www.npmjs.com/enterprise to manage this. If each team runs git fetch remotebase and git merge remotebase/master and runs npm install before ember deploy it will be manageable? Just thinking.
Well, the issue is more than managing their code bases. They all have different code bases. They can even use different tools: git, svn, mercurial. All I want from them is to put the generated assets (with ember build) to a specific directory.
Is there any way, to manage their index.html? I can create a parent page (with pure-html) and embed needed ember application to that page.
As a follow-up: Is it applicable managing their environment/config’s with a config server and passing current config to their applications with this pure-html page?
I’ve read the Readme, RFC; watched the introduction video; clone the repos and run the blog demo.
Below is my first thought, maybe will change after reading/learning more:
Motivation is the same with ours. Separated boundries, distributed development of apps… The requirement is clear: We need micro-frontends.
But I don’t like some points of the solution. You need to link your apps (engines) to the main app at some phase. If I didn’t misunderstand the linking occurs while building the main app. So I need to rebuild/redeploy the main app whenever an engine updated. But I don’t want to do that. Even any of the apps (engines) would do a minor bugfix, do I need to rebuild/redeploy the main app?
Main app shouldn’t be redeployed because of an engine redeployed. The linking should be established when a client browser loads the apps.
We have a large application suite in ember that runs along the lines of what you describe above (autonomous teams, different delivery schedules and tools).
At first the different applications were written in different technologies (ember, knockout, angular), and we used an iframe/postMessage strategy. Essentially the application shell was an ember app and the iframed apps would send messages to a service in the ember parent when a route change was required. That worked ok for a while, but we desired a single technology solution and moved to Engines.
We also want to start looking into a more efficient redeploy method for engines, but its not a big problem for us because we have the app in a continuous delivery pipeline. With lazy engines it seems more of a dynamic update scheme could be possible, since engines are compiled into their own js and css, but I can’t say I’ve looked into it enough yet to tell you for sure. I think there would be some complexities around validating shared dependencies though.
I’ve been locked at server-side for a while. So I’ve just watched your videos. First of all I need to thank you for your post.
There is a section on “What are the next decisions” in your slides. Do you have any improvements on these topics? I don’t like the idea of having a one-big deployment. Also sharing the dependencies sometimes would have problems. One of the apps might need to use an older version of an addon, while the others can upgrade the next version. Even iframe/postMessage strategy seems far better.
Despite of our server-side microservices; for now we are not using micro-frontends. But we are sliding our monolith client into small pieces.
I’ve read the Readme, RFC; watched the introduction video; clone the repos and run the blog demo.
Below is my first thought, maybe will change after reading/learning more: