Front-end Microservices at HelloFresh | Hacker News Reader

Front-end Microservices at HelloFresh

engineering.hellofresh.com

22 pointsmcenedella18 comments

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.

I couldn't agree more. I can't understand the desire to needlessly complicate applications, what ever happened to KISS and YAGNI.

Desperation to create the next new hot thing so one can get their 15 min? It's the only thing I can think of.

As much as most developers eschew the idea of the rock star developer, some are definitely taken by it.

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.

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.

Conway’s Law

http://www.melconway.com/Home/Conways_Law.html

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/). 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.

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.

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.

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.

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?

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?

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

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.

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.

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.

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

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

Reply on news.ycombinator.com