neuland / micro-frontends Goto Github PK
View Code? Open in Web Editor NEWextending the microservice paradigms to web development
Home Page: https://micro-frontends.org/
License: MIT License
extending the microservice paradigms to web development
Home Page: https://micro-frontends.org/
License: MIT License
I've been working on a rather large e-commerce project and the pattern we chose for our micro-frontends is a bit different from the vertical pattern you describe.
Basically, we have:
Part of our reasoning comes from the fact that we are transitioning from a monolithic legacy system to a microservices-based system and that transition implies different lifecycles for our back-end services and our front-end services. It's a lot easier for the latter to reach a stable "target" state, but the former will have to go through more evolution to reach that state. By decoupling the micro-frontends and the "micro-backends" (we don't call them like this, actually, but it seems to describe them quite well) we allow them to live separate lives and be deployed separately, in a more "atomic" manner.
Technically speaking, our micro-frontends are made of:
Thank you for the details and code which show how to use Web Components to create micro-frontends.
One issue I think you are not addressing is how to reuse existing components (be it React components, AngularJS components or vanilla JS components) between frameworks/libraries.
I'm working on a large scale frontend app which was built with AngularJS (1.x) for the past 5 years. There is a lot of functionality built with AngularJS code. We are evaluating migration to both Angular and React and I've also looked at micro-frontends as the only real solution to a vendor lock-in.
The problem is that in my reality it's not enough to use the technics you show here to be able to introduce new functionality or break exist monolith front-end to micro-frontends - I have to reuse at least some of the exist functionality otherwise we'll have to put in years to rebuilt everything in a different framework/library.
I understand what I'm asking is a technology-specific question but I think it's important enough to try and tackle it to make micro-frontends more accessible to existing applications.
This would be an important topic I guess. There are some JavaScript libraries, which do not allow multiple instances of themselves (like babel-polyfill).
How should we properly manage the dependencies, while maintaining a strong separation of concerns for Microservice teams? Building only one bundle could be a solution, but it might have side effects of which the too large size would perhaps be the least severe.
We are just experimenting with this now and trying to set this up (and in many ways we are at heavy "Under Construction"-phase). There might be some easy and clever ways, but since you didn't cover this so far, I would be very interested in your answer. Should there be a distinction of global libs and microservice specific libs? And of course, something which is not global, might still have two instances within different microservices.
I translated micro-frontend into Korean.
Can I use domain with github pages?
These are should be added.
<link rel="alternate" hreflang="ko" href="https://soobing.github.io/micro-frontends/" />
<a href="https://soobing.github.io/micro-frontends/">KR</a>
- [Soobin Bak](https://github.com/soobing) who translated the site to [Korean](https://soobing.github.io/micro-frontends/).
Thanks for nice article with examples 👍🏻
hi,I am a front-end developer from China, can I have the honor to translate this article into Chinese?
Their website is built with react and babelized.
To me it’s the only missing piece at the moment.
Do you have any ideas how that could be solved, yet?
So we could take any templating engine that has a
JavaScript verison, too which we could just run in
the browser i like i.e. TwigJS. But then we’d have
a requirement on using nodejs on the backend.
Hey,
Is there a tutorial on getting this to build. I have webpack installed, docker installed but getting this error.
team_red_1 | ERROR in Entry module not found: Error: Can't resolve './src/client.js' in '/code'
team_red_1 | npm ERR! code ELIFECYCLE
team_red_1 | npm ERR! errno 2
team_red_1 | npm ERR! [email protected] build: webpack -p
team_red_1 | npm ERR! Exit status 2
team_green_1 |
Thanks
We highlight micro-frontends as a major benefit to using web components with a headless CMS in our blog post. https://buttercms.com/blog/using-web-components-with-buttercms
Inclusion of the nodemon package to optimize encoding
Hi,
I have just been researching about micro-frontends for 2 months and it is really an exciting topic. Thank for your informative material.
I know that monolith & micro-frontends have their own strength and weakness, there is no silver bullet, but I want to ask you a question. "How can you convince people to use micro-frontends instead of monolith?"
I just want to know your ideas as a consultation, nothing more.
Thank in advance.
The website is often used as a source for the topic of micro-frontends. The IEEE citation standard requires online resources to include the date of creation (or last modification) in addition to the access date.
Would it be possible to display the date of the last (content-related) change somewhere? It is possible to track the last change via the commits, but it would certainly be nicer to display the date directly on the website.
Even better, but of course optional: direct copying of a bibtext entry with all the information. It could look like this, for example:
@Online{microfrontends,
title = {Micro {Frontends} - extending the microservice idea to frontend development},
year = {20??},
url = {https://micro-frontends.org/},
urldate = {20??-??-??},
}
The website says 'share common resources between teams' but I wasn't able to find detailed information about this topic.
If two teams use the same technology (let's say React) how can they prevent the client from loading a huge amount of assets (in particular the whole react vendor)?
I like the idea of verticalization and that each team is completely independent (own backend, own database, own frontend) but when it comes to frontend I'm afraid the client has to lead much much more compared to a frontend service that gets used by all (backend) verticals.
I don't wanna lose features such as webpack's code splitting.
Are there any best practises?
I have read few blogs and it makes sense to have error handling responsibility given to each micro-frontend.
But there might be scenarios where among micro-frontend you would like to have consistency in handling common errors specially for api status 400/500 ones. If we extract api abstraction layer into a package or in orchestrator application where should we put our error handling mechanism?
With the latest commit, team blue is missing! Therefore the DockerFile
can't find it.
The topic.
Hi!! Im trying to run your examples on Ubuntu 16.04. Looks like everything is working fine except the page renders without CSS.
I got this error on the console:
nginx_1 | 2018/10/16 18:10:25 [error] 7#7: *1 open() "/usr/share/nginx/html/common/page.css" failed (13: Permission denied), client: 172.19.0.1, server: , request: "GET /common/page.css HTTP/1.1", host: "127.0.0.1:3000", referrer: "http://127.0.0.1:3000/"
Would you, please, help me? Thanks!
Hi there,
I hope I'm writing in the right section (otherwise I'll move it wherever it belongs).
I've been trying to implement the microservice architecture but even though I managed to run two different applications on the same page, I've been struggling a bit to get how to implement a proper routing.
In the website and in the videos I watched you talk about a top-level routing. Has this to be implemented in NGINX (for instance)?
How should I use this model if I need to create routes at the component level, like inner/sub-routes?
Many Thanks,
A.
The Java Portlet Specification (Wikipedia) more or less tries to cover exactly what this project is all about, but the concept of a Component is called Portlet, and the scope of a “unit of functional collaboration” is a little bit bigger (a Portlet is a big page fragment, while a Component tends to be smaller).
There are many implementation of those specifications, but I suggest you to have a look at Liferay’s.
Hi,
I've adopted the static files example to run on Netlify.
I've deploy each team as different deployment and use redirects
file to route requests to each team.
I can create a PR if you think it is good.
I have tried to conceptualize microfrontend with Angular7 using angular-elements.
Not sure how and where to use <#include > with ngix which can intercept URLs.
Any plan to go in that road?
Does anyone of us have ready made demo / template project about this?
It seems, that I am going to give a presentation about this architectural style and might want to create such project as a by product if one doesn't already exist. I do not consider myself as an expert on the topic (I prefer more Data Science and more back end stuff) so I would prefer using someone else's ideas / feedback on my thinking how this works.
So far, we are building something like this:
-We use LoopBack for MicroService backend.
-We use LoopBack Passport component for authentication.
-We use Nginx as a proxy, so that domain.com/api/ServiceA/ApiV/Resource.., domain.com/api/ServiceB/ApiV/Resource.. will match each LoopBack backend (this way we can later handle service registration and load balancing easily).
-(Each service has to have access to the authentication database, because LoopBack Passport works that way; I kind of don't like that, but it is how we do it now).
-We also use Nginx as a proxy for serving the front ends of each service like domain.com/web-component/ServiceA/component1.html, domain.com/web-component/ServiceA/component2.html, domain.com/web-component/ServiceB/component1.html etc.
-Then we have the main index.html, which has some ideas about the route, from which the "global single page app" -- which contains all the microfrontends -- was accessed. Then it uses SSI to load only what it needs, because the bundles can be quite big at times. It also loads the global dependencies and common dependencies, which are not component specific.
Would there be some aspects, which I have forgotten? Each component contains self contained assetts built by Webpack etc.
Simple TODO list with authentication might provide a nice demo application.
Thanks for this interesting idea.
https://github.com/neuland/micro-frontends/blob/master/ressources/screen/three-teams.png seems to indicate that the three teams should use three different frameworks (Vue, React, Angular). At least the logos for these frameworks are present in the screen. However, that is not what the example code seems to use. Also this approach would use a lot of resources and slow down loading the application and page. It would therefore be great to remove the logos from the figure. Also it would be great if the page explicitly talk about the problems such a multitude of frameworks might cause.
Hi @neuland! Is this project active?
You're mentioned here:
I am looking for reference to develop wizard using micro-frontends. I suppose the navigation reference should cover it. Do you have any ETA for it? Or any documentation how to achieve it?
Hi there.
I did translate micro-frontends to Portuguese, but I don't buy a domain like in JP and ES version.
Can I keep in my own github page domain?
Where in the code does it actually use angular? Would it have to be done differently if you are trying to server side render angular? Is there a way to contact you to talk more in depth on this?
https://github.com/GrosSacASac/DOM99/blob/master/examples/js/microBlueBuy.js
I recently added dom99create.js specifically with micro frontends in mind. The main idea is that the framework code could be reused with different options.
In the example blue-buy I wrapped the module into a custom element so that it can be added via document.createElement("blue-buy")
I would appreciate feedback if there is some mistake for example
Hi Guys,
I've read (and loved) your website.
I couldn't help but think that the paradigm you describe is almost 1:1 implemented by Bit:
https://github.com/teambit/bit
I was thinking it can be very helpful to refer to Bit from the website + GitHub as an (perhaps the only full one) implementation of a tool built for this paradigm. Would love to know what you think.
Thanks
Consider to add a section or a wiki page which mentions tooling to build micro-frontends without browser frameworks:
Here, we are planning to move all of our common components to one different repo and then integrate it with with our all other portals which are on again different different repos. My question is, how to integrate it? I tried to integrate it in package.json and fetch repo along with branch as module. But that didn't worked on azure. Now, I am going to try git submodules. Please tell me is it a correct way or do I need to try something else?
Hi, I translated micro-frontend into Polish.
These are should be added.
<link rel="alternate" hreflang="pl" href="https://dominikcz.github.io/micro-frontends/" />
<a href="https://dominikcz.github.io/micro-frontends/">PL</a>
- [Dominik Czechowski](https://github.com/dominikcz) who translated the site to [Polish](https://dominikcz.github.io/micro-frontends/).
Thank you for your great work ❤
Thanks about your micro-frontends initiative. I was inspired and made my own framework.
https://github.com/afsec/cellular-js
Cheers!
As a micro frontend architecture with teams updating independently, it's a good idea to have some level of integration testing. How can this be handled? Does the overall container application specify a specific version of each component it's loading?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.