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.
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