Reasons for Doing Microfront Ends
dev.to
dev.to
Since the article mentions Piral, I thought I would peruse that project's documentation (0), but am none the wiser on basic questions like: how do components get assembled into the main application, is network traffic overhead is going to be a problem, etc.
Delving further into the Piral docs, I came across a link to a sample micro-frontend (1) that seems to be importing every micro-frontend into the index, so network traffic overhead seems like it could be an issue.
Does anyone here have experience with these in a production environment and know how to avoid (in my mind) basic pitfalls like these? As it stands, this article seems to be setting people up for scenarios like the Bell micro-services disaster (2)
[0] https://github.com/smapiot/piral/blob/develop/docs
[1] https://github.com/benjamminj/micro-frontends-examples/tree/...
> I would have liked the article to start off by listing the use cases and trade-offs instead of jumping right on the hype train at full speed.
Well, the use cases are pretty much large scale applications that are developed by multiple teams. We had clients like that in the past and we currently have 2 clients that have such a set up.
Point being if you just want to transport a single functionality or if the whole frontend just serves a single purpose then don't think about microfrontends.
What should I have mentioned here? Can you give an example? Happy to improve to post here!
> how do components get assembled into the main application, is network traffic overhead is going to be a problem, etc.
Maybe we should have the architecture diagram on the main page of the documentation, but maybe this contains what you are after: https://docs.piral.io/reference/documentation/reference
Otherwise have a look at: https://dev.to/florianrappl/microfrontends-based-on-react-4o...
Network traffic should not be much of a problem: If you render everything client-side you may (!) have more requests than usual (may, since you will / should use bundle splitting anyway), however, if that is a problem you can already fuse your app server-side.
We would love to improve the documentation and make it more accessible. Can you tell me what you've been looking for specifically? Any input appreciated!
> this article seems to be setting people up for scenarios like the Bell micro-services disaster
Sorry, actually it was meant for the opposite, i.e., if you don't have any of these reasons then don't do it.
Just to be clear: The beauty of a solution like Piral is that you can just start development of a new feature without touching the rest of application. You also deploy independently.
How it works is as follows: Each pilet (= a microfrontend in Piral) is produced as a kind of library that is self-contained and exports a function which is called later at runtime (here assumed client-side, but works the same on server-side).
The only question is now: How is the web app knowing what libraries to load? This is where the crucial component - the "feed service" is coming into play. This is the missing piece of infrastructure. This service exposes an endpoint to be queried for obtaining what libraries to load for the current user.
Hope that helps!