
Reasons for Doing Microfront Ends - FlorianRappl
https://dev.to/florianrappl/5-reasons-for-doing-microfrontends-1mba
======
etripe
As your average developer who's heard architects mention these micro-
frontends, 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.

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](https://github.com/smapiot/piral/blob/develop/docs)

[1] [https://github.com/benjamminj/micro-frontends-
examples/tree/...](https://github.com/benjamminj/micro-frontends-
examples/tree/master)

[2] [https://www.youtube.com/watch?v=gfh-
VCTwMw8](https://www.youtube.com/watch?v=gfh-VCTwMw8)

~~~
FlorianRappl
Thanks for addressing these. I'll try to answer most of them:

> 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](https://docs.piral.io/reference/documentation/reference)

Otherwise have a look at: [https://dev.to/florianrappl/microfrontends-based-
on-react-4o...](https://dev.to/florianrappl/microfrontends-based-on-
react-4oo9)

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!

