
Micro Front ends – extending the microservice idea to front end development - fagnerbrack
https://micro-frontends.org/
======
hectorlorenzo
I really really don't like the idea of having 3 different runtime libraries
(or maybe even the same library with slightly different versions) loading at
the same time.

It's quite unanswered how are they dealing with styling. There's always a
specific percentage of styles being shared between components. Should we
duplicate these styles? I see they are going to talk about it soon (Isolated
CSS / Coherent User Interface / Style Guides & Pattern Libraries).

One of the biggest joys that I had recently in front-end development is the
idea of a one-way, cross-application shared state. This goes away, too.

Maybe I'm just being hyper-conservative. I need examples of the benefits of
this approach in something that it's not a simple product picker.

~~~
Kiro
> There's always a specific percentage of styles being shared between
> components.

I used to think that but nowadays I very seldom come across a situation where
sharing styles make sense. I'm trying to make my components completely
isolated, styles included. I'm doing CSS-in-JS and if I really need to share
something (say a primary color) I import it from an explicitly shared module
called "colors". This leads to some duplication but when I change something I
know it will only affect that component.

~~~
barryhoodlum
After using tachyons ([http://tachyons.io/](http://tachyons.io/)) I've gone
the complete opposite direction. While tachyons takes it to an extreme, I
found having many small classes that (generally) do one thing, then composing
those classes in the HTML, is much nicer than giving each element one
"semantic" class name and hiding all the complexity in the CSS, with the large
file size and many duplicate rules that approach brings.

You are then not scared of changing existing classes, as they are so simple.
In fact you rarely have to change them after writing them the first time.
Often you can build a whole new component without writing any new CSS.

It works especially well with components, as it's OK if the HTML is "noisy"
with many class names, as generally you're not dealing with large chunks of
HTML at once.

~~~
devdad
I actually take it one step further and have classes such as `border-1-px
border-dark border-bottom standard-margin no-margin-top`. Seem weird at first
but combined with flexbox (if your target is the evergreens) you never
overwrite and you got one stylesheet for pretty much all of your projects.
It's a real production boost.

Really not a fan of CSS-in-JS. I like to keep my components JS+JSX only.

------
stingraycharles
I think this is an artifact of domain driven design taken too far. Perhaps it
works well in organisations like Netflix, Spotify, etc but I would tread very
carefully with this indeed in an organisation with less engineers.

I always find that these domain boundaries in which teams operate are “leaky”,
and result to noticable inconsistencies between them to the end-user. If you
can’t afford the overhead of making sure that these inconsistencies are caught
and fixed, don’t do this.

~~~
glenjamin
Both this and microservices are primarily tools to attempt to make it possible
to scale software teams to large numbers of people.

If you don't have a need to scale to large numbers of people, you almost
certainly shouldn't attempt to apply these techniques.

~~~
DigitalJack
I feel like there is another aspect that is helpful. It's another way to
partition an application into surmountable "bite size" chunks. There are
plenty of other ways to do this, but if this is what helps you think about the
problem, go for it.

------
weego
This just seems like a mess of existing ideas and abstractions mashed into a
pseudo-philosophy.

~~~
coldtea
It only looks like that because it is.

------
tzahola
The article implies that you should architect your system around your existing
team boundaries. This is harmful and counterproductive. You should identify
the sub-units of your system first, and then you can come up with an
organizational structure that work effectively with your architecture.

~~~
icebraining
I think the idea is that you've already done that on the backend, and you're
just extending it to the frontend.

~~~
tyingq
There are unique downsides of extending it there. Bloated downloads and less
caching benefit since pages need competing frameworks. How to deal with shared
elements like a cart widget or login widget. Overlap...search results and
shopping pages may be very similar on an ecommerce site. Their example shows
those as 2 separate teams able to make all of their own stack decisions.

------
aaimnr
"Custom Elements, the interoperability aspect from the Web Components Spec,
are a good primitive for integration in the browser. Each team builds their
component using their web technology of choice and wraps it inside a Custom
Element (e.g. <order-minicart></order-minicart>). The DOM specification of
this particular element (tag-name, attributes & events) acts as the contract
or public API for other teams. The advantage is that they can use the
component and its functionality without having to know the implementation.
They just have to be able to interact with the DOM."

Seems like an interesting idea, but it's barely supported at the moment:
[https://caniuse.com/#search=custom](https://caniuse.com/#search=custom)

~~~
allover
> Seems like an interesting idea, but it's barely supported at the moment

You can polyfill custom-elements to all evergreen browsers plus IE11 [1], but
yeah that's not good enough for a lot of sites.

[1] [https://github.com/webcomponents/webcomponentsjs#browser-
sup...](https://github.com/webcomponents/webcomponentsjs#browser-support)

------
oh-kumudo
How could u prove it is useful outside of the example in the article? I found
several listed goodies of this idea pretty questionable. Weirdly feel like a
renaissance of the old architecture astronauts.

------
coldtea
"Let's take a bad idea to its slippery slope conclusion"

------
partycoder
Basically this promotes the idea of "full stack microservices".

The problem is that many "full stack" people do not live up to their
denomination and when you have all-full stack teams you are raising the odds
for having people who are weak at backend engineering.

That is absolutely not something you want. Backend bugs can be catastrophic.

e.g: a guy in team checkout may not know what happens when you process
currency with floating point numbers.

~~~
icebraining
I think this is intended for large organizations, where you can have
specialists on each team - e.g. instead of having a "backend team" of thirty
developers and a "frontend team" of twenty, you might have five teams each
with six backend and four frontend developers.

------
proc0
Inherently, UI IS state. Anytime you have a user interface, you literally are
writing software to manage state of some kind. Take the TV remote... the user
controls the state of the TV, namely the channels, and properties like volume.
The remote is an interface to change this state. Microservices is like trying
to solve the problem of a really, really complicate TV with crazy channels and
multiple volume properties by creating 10 different isolated controllers. It
won't work because there exists a shared state, yet each controller is aiming
to not share any state while still having a scaleable system. This is of
course only possible in simpler UI's, because the more complex the UI, the
more state will need to be shared, unless you want to throw away DRY
principles and duplicate logic and styles all over what is seemingly the same
app.

------
sametmax
Shameful but relevant plus here, the Foss project crossbar.io helps with that
kind of thinking. It creates transparent pub/sub and routed rpc that work
between microservices and cross languages. But because it uses websocket as a
transport, it also work with no adjustments in the browser.

------
pier25
We do something similar in our company because it's easier to manage many
small projects than less bigger ones. It requires less people per project
which in turn requires less communication overhead and since projects are way
simpler productivity is also better.

Our backend is a monolith so all our front end projects use the same login
credentials, permissions, etc.

So far our users are ok with this approach, and since we build projects for
certain departments / teams there is no argument to justify having all the
front end functionality in one place.

Another benefit of having smaller front end projects is being able to
experiment with stuff instead of having to stick with the same libraries /
stack / mistakes from the past. I reckon this is a double edged sword, but it
works for us so far.

------
plq
The web rediscovers what Delphi, VB and similar tech did at nineties --
components :)

From my limited exposure to the subject, Google's Polymer framework seems like
a good base to build on if you are willing to drink the web components kool-
aid.

------
tuan
I feel like Microservice idea does not seem to translate well to front end.
When thinking of microservices, one can think of collection of well
encapsulated functions that are composed together. The keywords are function &
encapsulation. This is not usually the case for frontend development. UI
components in the same app can't be completed sealed off of each other. You
can model UI component as functions of state, but those functions usually
depend on at least 2 globals: DOM event system and styling. This is where
encapsulation is broken and leads to all sort of maintenance issues.

~~~
proc0
In other words, UI manages monolithic state by definition. Whenever you're
able to completely break off from the monolithic state, then probably that
logic can be its own app. Typically this is not the case with widgets on the
same screen. Usually you want UIs to display integrated data of some kind,
that is intertwined with the rest of the app somehow.

------
nine_k
At Yandex ca 2006, we had a microservice-like system that allowed to build
various parts of a large page in parallel, using a graph of microservice
dependencies.

Every microservice ("servant") would reply with an XML document. The partial
documents would compose into a large XML document, and an XSLT stylesheed
would be applied to it by the renderer service. This allowed to decouple the
visual design from microservices' data format, allowed (limited) customization
of visual representation of one service's answer depending on data from
another, etc.

It worked pretty well, and felt natural.

------
DasIch
Zalando does this as well with Mosaic:
[https://www.mosaic9.org](https://www.mosaic9.org)

If you don't have a few hundred people working on the frontend in many
different teams, don't try this. This first and foremost solves the problem of
coordinating and communicating between these teams by eliminating (some of)
the need to do that. There is nothing to gain and a lot of overhead to deal
with, if you're in a company without so many engineers.

------
EGreg
We've already been doing something very similar at Qbix:

[https://qbix.com/platform/guide/tools](https://qbix.com/platform/guide/tools)

Tools can add behaviors to elements. So customElements will be very easy to
add once they are supported by more browsers, or we can already do it with a
polyfill.

But yeah, being able to assemble webpages from reusable components is
excellent.

------
usgroup
The team I work with is partitioned across 3 dev languages. Micro services on
the backend make a lot of sense for that reason.

i like the idea of running potentially separate apps under separate URLs for
the front end because it keeps an artificial encapsulation which allows devs
with different js stack knowledge to work to their strengths. It also means
one can progressively rewrite when the time comes.

------
tyingq
_" Each team should be able to choose and upgrade their stack without having
to coordinate with other teams_"

Yikes. At what level of granularity? Do they mean within a single project?
Like an ecommerce app where the shopping and checkout teams get to pick
completely different front end stacks?

------
Xoros
So it's the widget come back ? One for the weather forecast, one for stock
exchange informations...

~~~
tyingq
Ugh. Java portlets.

------
je42
Interesting . We are calling this approach internally: component-based. Other
names, i heard were widget based.

------
xj9
you mean components?

------
baybal2
I feel this is how it was when Angular 1.0 concept was laid.

Worked great for some time. Then the original idea was buried under many
layers of "abstract stuff CS postdocs like to play with"

------
bradmwalker
Encapsulation can be useful.

------
adityapurwa
Read it, seems complicated, will not use it.

