
Front-end Microservices at HelloFresh - mcenedella
https://engineering.hellofresh.com/front-end-microservices-at-hellofresh-23978a611b87
======
sergiotapia
Am I the only one who thinks this is insane and a product of an architecture
astronaut? Their whole workflow sounds absolutely exhausting and something
ripped straight from the movie Brazil. Layers upon layers upon layer. This is
nuts.

~~~
dboreham
There's a rule (I forget who pointed it out first, I heard it in 1994 or so)
that the structure of a software system will exactly mirror the structure of
the organization that created it.

~~~
devonkim
[https://en.m.wikipedia.org/wiki/Conway%27s_law](https://en.m.wikipedia.org/wiki/Conway%27s_law)

It turns out that there’s some academic backing to this original observation
and it’s partly what is driving some really controversial organizational
changes at larger software companies.

------
TN1ck
The Problem with this whole concept of Microservices for the frontend is, that
it can't really work out due to the constraints of the frontend: Every byte
counts. It does matter how a component is written and which framework you
used, as you don't want to load 2MB of Javascript for every new page. This is
in contrast to the classical Microservices, where it absolutely doesn't matter
how big each of them is.

So of course I checked their new site, that was written with this architecture
([https://www.hellofresh.com/shop/](https://www.hellofresh.com/shop/)). Could
they solve this problem?

In total, they transmit ~770KB of minified JavaScript with an activated
adblocker. This is quite a lot, at my last company we had a big react app with
70K LOC and a number of used libraries. It served about 800KB of minified
JavaScript.

They load React, ReactDom, Immutabble and Axios separately to avoid having
them duplicated, which accounts to ~67KB. So what are the 700KB doing?

219KB for a shop fragment 135KB for the header particle 96KB for the footer
particle

The last 250KB is some API stuff called api_static and api_dynamic.

I can't really tell how sophisticated the shop is with its 219KB, but having a
96KB Footer and 135KB Header should raise some doubts, how is this possible? A
React Footer should be 1KB or something. As I checked the source code I found
mainly vendor code and as far as I can tell it's duplicated among the source
files.

For me this shows me, that they couldn't solve the problems that arise with
such an architecture and I doubt that there will be anything that solves these
issues (without putting a lot of burden on the developers) in the near future.

------
incadenza
I don't know. This trend is potentially interesting, but the stated benefits
don't seem to match up to the cognitive overhead involved in an architecture
like this. Also not convinced it's worth adopting three different JS
frameworks in an application.

Maybe I'm missing something, but what does this accomplish that code splitting
/ server side rendering doesn't? If there were performance gains, that would
be interesting to know as well.

------
rco8786
Applaud the effort, and obviously I don't have the insight into the
motivations behind the decisions, but I don't see this ending well.

Why have multiple SPA frameworks on a single page? What happens when one
fragment is built in React X.X and another in React Y.Y? It feels like you
have to pull a bunch of different pieces together to form what would formerly
be known as a "route" in more traditional webapps, and I'm not really seeing
the upside here.

I hope we get a follow-up in 6-12 months about where this experiment goes.

~~~
DasIch
Not sure about HelloFresh but at Zalando there are rules for that all
fragments are supposed to follow so that this doesn't happen. In practice that
means everyone has to use React in the same version, there is a shared library
of components for grids, buttons to achieve consistency in look and feel and
so on.

You could have multiple SPAs in the same page but you don't actually do that
in practice.

You do this not because this is simple, not to create a better user experience
but so that you can have 100+ teams working on the site without them being
stuck because every change needs to be carefully coordinated with everyone
else.

~~~
rco8786
Could you expand on that last bit? If I’m working on one part of the site and
someone else is working on another, what sort of coordination problems do we
have? If we’re both working on the same part, sure, but it’s not clear to me
how the approach laid out in OP fixes that?

------
albertgoeswoof
Hellofresh deliver packages of ingredients, menus etc.

I can’t imagine that this is a problem that requires a bleeding-edge _front
end web technology_ to solve. ML tech, some cool logistics methodology, an
awesome menu/price algorithm etc are things that I would expect to see. But
this seems a bit over the top?

~~~
brianwawok
The devs got bored. Bored devs do this kind of stuff.

------
pm24601
What is old is new again. This is the original "portal" idea that was used
back in the 1996-2000 days of Yahoo.

This is also the same technique I have used at companies that need to present
an "integrated" view.

For example, an internal HR web site that presents a single page of all things
related to an employee benefits.

The information would come from multiple different services:

* ADP for payroll

* Fidelity for 401k

* An interval vacation tracker

* etc.

Each service would be given their own iframe that they control. No needs to
worry about anything outside the iframe.

This is a time-proven way to do an integrated presentation of independent
systems.

To clean up the look and feel - use basic html transformations and inject the
site css.

It may seem "hacky" \- but it works well in many many real world
circumstances.

------
DasIch
I would really like to know why they decided against the Zalando approach.
Mosaic is open source, so they could have taken advantage of the same code
Zalando uses and gotten improvements there for free.

------
paradygm
The problem they were trying to solve isn't clearly stated, it just seems like
they wanted to come up with something they could call 'microservices' in the
front end. It reads like something out of the 90s when the 'Design Patterns'
book came out and many were blindly implementing the patterns, just to see if
they could.

~~~
JustSomeNobody
Worse. It's when 'Design Patterns' came out and developers tried to "create"
or "invent" their own pattern.

------
camus2
front-end microservices? but what or who do they serve? they don't serve data,
so they are not services, they are clients.

