guide to micro frontends are provided at the end.
Hi there! Heard of the iframe? Of course! If you haven't it's probably because it's older than you are.
The Iframe gets a bad wrap and it's not all unjustified. But at the same time, it deserve respect.
I was challenged recently to build a micro frontend loader for some ideas we have. This lead me down multiple path ways.
My first response was "yikes, this may need iframe... but I don't wanna use an iframe, it feels bad".
I started out strong. I came up with an idea in my head, put it to code and boom! It worked! I had multiple react apps, with different versions of react, hosted on different host, all working as 1 single site.
The value in this was to allow us to update any of the remote sites, without ever having to release the host website.
I used javascript to dynamically load an iframe, then pushed the javascript bundle to that iframe. Once the iframe loaded, it attached a reference to itself and handed that off to the host.
The host was then able to let it know when to mount and give it the dom element to mount to.
All worked way to well right out the gate. Anytime something works flawlessly the first time, you should be paranoid...
Welp! Sure enough, it worked. Great! First time and I've got my work done.
Not so fast! As soon as I added react style-components to the host, the fires started.
Styled-components had this issue (which they fixed), where if there was multiple instances of styled-components, it would overwrite each other.
Being that I just bundled an entire website and it's modules, then mounted it to the current site... There is of course going to be multiple instances. They may be encapsulated, but only have a single DOM to work with.
Styled-components is nice enough to warn you when you have 2 instance running so props to them.
Well my buddy at work found the fix and we were back to a working micro frontend solution.
But it left me scarred. What if we have another library that does the same thing? We have to now be very mindful of every single action, every package takes. Unrealistic.
The whole point of avoiding the use of iframe was to avoid the overhead of issues and work arounds. But at least with the iframe, it's issues are known and have years of vetted testing, and solid solutions.
So we had the long talk about what to do. Do we keep this working version and just risk the chance that weird little bugs could show up with no real view into why?
Or do we just quit avoiding iframe and go with it, since it ensures encapsulation?
Iframe it was.
Using js, I dynamically created an iframe based off of a manifest. It allows prop passing, so you can have initial values to start your app with.
I used the postMessage api to communicate further information between the parent and child.
This got me what I needed.
Some of the pros/cons?
- pro: it ensures encapsulation
- con: encapsulation also means harder to modify parent/child from each other.
- pro: very easy to implement
- pro: provides an api for cross communication
- pro: adds in additional security
- con: makes working with sessions difficult
- con: makes iframe content sizing to host difficult
- pro: allows you to have an index page to build off of
- con: you have to specifically code to an iframe, which requires knowing what minor difference that is
Those were just the first few off the top of my head.
What is your experience with iframe? What was your solution for micro frontends loading? Let't talk!
If you want to learn more about micro frontends, here are a few references.
Top comments (2)
Great article!
I would add that postMessage is a very low-levelish API suited for simple cases of communication, so as for "con: makes working with sessions difficult" - that's exactly why I wrote a library called iFramily (github.com/EkoLabs/iframily) which simplifies communication between frames.
The idea was to provide a simpler API than postMessage, which includes Promise-based responses, message queuing, and manages the connection until both frames are ready to talk. It also takes a responsible approach and keeps the developers’ security responsibilities front and center.
Would love to hear your thoughts!
Nice Article!!
Is it the same approach where we build out different apps in different frameworks and load all of the macroapps via iframes and connect them via an event bus?
Will you be able to share any Github Repo for the same. Would love to see the code