I don't understand what they are still. Are micro-frontends just multiple frontends for the same backend? If so, what's micro about that? I feel like I'm missing something.
I think that it's best to first understand the concept of microservices. Microservices are essentially independent "mini-backends" that contain functionality for a particular domain or function. Micro frontends are the same thing, except with frontend code.
The idea is that multiple micro frontends can communicate with each other and work well together, without needing to co-depend too much. There are many additional pros and cons that I cover in my video above. :)
Apologies that the video doesn't do a good job of laying the context and explaining what it is. Here is a (hopefully) clearer explanation.
Firstly lets assume things at scale.
Multiple frontends are a bunch of seperate apps talking to one or many API's, each can come from one or many backends. (This seems to be the norm right now)
I picked the above example to show that Backends are not 1:1 to api's and apis are not 1:1 to frontends. they are all many to many relationships. This doesn't change whether using micro-frontends or not.
A micro frontend, is a single (just one of those) app cut up in ways such that it will be composed of multiple smaller self contained parts. Example: For browse and stream, It's one website. You don't want the page to refresh between browsing and streaming. Maybe you can stream as you browse (like youtube). So you cut it up code wise as browse and stream. But the UI/UX is the exact same, the user (ideally) should not be able to tell its 2 seperate apps.
Right now you have all the functionality in one repo and most likely sharing the same frame work. Micro-frontend is playing with the suggestion that you can completely seperate certain bits. Such that the ONLY assumption is they communicate via a contact (they have to co-ordinate with each other somehow)
So the most basic implementation is just have browse and stream sit on 2 seperate sub-domains. and drop 2 iframes into one page. Then the communication is via window.postmessage and window.onmessage. So when you click on something in browse it will pretty much broadcast to the stream app that it's clicked on a song and stream just handles that message. There are ofcourse more elegant ways by what was briefly discussed in the video as the Frame.
What this does is basically split the app into multiple projects. You can start to build smaller teams that are solely responsible for smaller parts. You can use different technology or CI processes to build each one. You can even put them on different repositories one on svn one on git. Can be hosted on different stacks. The long-winded discussion about tradeoffs and benefits is in the video ;)
Would also like to add the relationship between this and Web Components is... Currently a React.Component is a React component with the contract defined by React (props). Web component is supposed to be generic, and fully encapsulated. So we need to think of ways for Components of different technologies and even different versions of the same tech to generically communicate.
In the video we go in depth about this... There are reasons but I think the host and I both feel the true benefits are harnessed in very niche cases and a good Components model can provide most if not all the benefits at this point in time.
As for the 2 iframe thing. Spotify is actually done like that, so it is currently being successfully used in a large scale production app that most people would say is a leader in the industry. It's also worth noting that some of the problems it solves is not technical but organisational. So even though from a computer science perspective it may seem a bit silly, but from certain organisation/management perspectives it might actually make alot of sense.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
I believe you missed the point of microservices in the first place. They are in most cases isolated programs trying to solve domain specific problems. Typically they run on the same backend framework. So a microservice-based application runs on the very same Java or .Net version. In a containerised deployment they can even use exactly the same container image. The result is unification, shared resources and integration.
The "micro-frontend" is exactly the opposite.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
Think of having multiple different states and problems synchronizing them. Think of CSRF tokens, think of CORS and associated maintenance hell. Think of multiple cookies. Think of authentication and authorization. Think of having downloaded multiple identical or different frameworks, all the duplicated string objects, translations loaded into memory just wasting it. Think of synchronized loading of complex screen with tens of components and making sure everything is up to date and represents ground truth. Unless I ever see a working PoC that does not bring my system to a halt and will not present more problems than SPA I'm not a fan at all...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't understand what they are still. Are micro-frontends just multiple frontends for the same backend? If so, what's micro about that? I feel like I'm missing something.
I think that it's best to first understand the concept of microservices. Microservices are essentially independent "mini-backends" that contain functionality for a particular domain or function. Micro frontends are the same thing, except with frontend code.
The idea is that multiple micro frontends can communicate with each other and work well together, without needing to co-depend too much. There are many additional pros and cons that I cover in my video above. :)
But what are they? How are they not simply multiple frontends for the same backend? Do the frontends communicate with each other? How and why?
Videos are great, but I prefer reading.
Apologies that the video doesn't do a good job of laying the context and explaining what it is. Here is a (hopefully) clearer explanation.
Firstly lets assume things at scale.
Multiple frontends are a bunch of seperate apps talking to one or many API's, each can come from one or many backends. (This seems to be the norm right now)
Example:
I picked the above example to show that Backends are not 1:1 to api's and apis are not 1:1 to frontends. they are all many to many relationships. This doesn't change whether using micro-frontends or not.
A micro frontend, is a single (just one of those) app cut up in ways such that it will be composed of multiple smaller self contained parts. Example: For
browse and stream, It's one website. You don't want the page to refresh between browsing and streaming. Maybe you can stream as you browse (like youtube). So you cut it up code wise asbrowseandstream. But the UI/UX is the exact same, the user (ideally) should not be able to tell its 2 seperate apps.Right now you have all the functionality in one repo and most likely sharing the same frame work. Micro-frontend is playing with the suggestion that you can completely seperate certain bits. Such that the ONLY assumption is they communicate via a contact (they have to co-ordinate with each other somehow)
So the most basic implementation is just have browse and stream sit on 2 seperate sub-domains. and drop 2 iframes into one page. Then the communication is via
window.postmessageandwindow.onmessage. So when you click on something inbrowseit will pretty much broadcast to thestreamapp that it's clicked on a song and stream just handles that message. There are ofcourse more elegant ways by what was briefly discussed in the video as theFrame.What this does is basically split the app into multiple projects. You can start to build smaller teams that are solely responsible for smaller parts. You can use different technology or CI processes to build each one. You can even put them on different repositories one on svn one on git. Can be hosted on different stacks. The long-winded discussion about tradeoffs and benefits is in the video ;)
Would also like to add the relationship between this and Web Components is... Currently a React.Component is a React component with the
contractdefined by React (props). Web component is supposed to be generic, and fully encapsulated. So we need to think of ways for Components of different technologies and even different versions of the same tech to generically communicate.Why would you iframe 2 components from 2 separate frontends into a 3rd SPA frontend instead of just using 2 components in your SPA
In the video we go in depth about this... There are reasons but I think the host and I both feel the true benefits are harnessed in very niche cases and a good Components model can provide most if not all the benefits at this point in time.
As for the 2 iframe thing. Spotify is actually done like that, so it is currently being successfully used in a large scale production app that most people would say is a leader in the industry. It's also worth noting that some of the problems it solves is not technical but organisational. So even though from a computer science perspective it may seem a bit silly, but from certain organisation/management perspectives it might actually make alot of sense.
Cool. Please describe where I can see Spotify doing this
If you are still interested in learning about service oriented architecture for frontend I have written a post on this topic here
I believe you missed the point of microservices in the first place. They are in most cases isolated programs trying to solve domain specific problems. Typically they run on the same backend framework. So a microservice-based application runs on the very same Java or .Net version. In a containerised deployment they can even use exactly the same container image. The result is unification, shared resources and integration.
The "micro-frontend" is exactly the opposite.
I suppose that was my point.
This makes absolutely no sense.
Think of having multiple different states and problems synchronizing them. Think of CSRF tokens, think of CORS and associated maintenance hell. Think of multiple cookies. Think of authentication and authorization. Think of having downloaded multiple identical or different frameworks, all the duplicated string objects, translations loaded into memory just wasting it. Think of synchronized loading of complex screen with tens of components and making sure everything is up to date and represents ground truth. Unless I ever see a working PoC that does not bring my system to a halt and will not present more problems than SPA I'm not a fan at all...