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.
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.
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.
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?
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.
