
Front-End Microservices - kostspielig
https://jobs.zalando.com/tech/blog/front-end-micro-services/
======
49531
I've worked on a product that was built using "Front-end Microservices".
Probably one of the harder development platforms I've ever run into.

It takes a lot of diligence and uncommon knowledge to do it successfully. For
instance, when I started on this project, each "microservice" was deployed
individually, meaning if you went from /account to /product you were loading
an entirely different app. This gave users an initial page load several times
during a typical workflow.

I currently work on a massive monolith which ties our entire backend and
frontend together in one app. It's a little clunky but overall it makes it a
lot easier for my team and me to ship reliable code.

------
kyberias
It's like these companies live in a totally separate universe where none of
the normal software engineering principles apply any more. The micro services
cargo cult permeates everything.

~~~
quanticle
This front-end micro-services architecture looks a lot like how Amazon renders
its pages. Amazon's rendering framework takes in components from various
teams, renders their components, assembles it all into a final page and then
sends it to the client. In theory, this allows all the the benefits promised
by the article: teams can use whatever frameworks they want, they can
architect their part of the page in a manner that suits them, etc.

In practice, it's a mess. Just go to Amazon.com and open the page in the DOM
inspector, or view-source. There's no consistency between any of the page
components. Things are duplicated. Things are coupled to each other in weird
ways. It looks like an absolute nightmare to debug.

~~~
kronin
Amazon has invested significantly in tooling that makes debugging this
possible.

I would not recommend anyone go down this route unless they are also willing
to invest heavily in the tooling support necessary.

~~~
tabtab
So the "remedy" to bigger spaghetti is a bigger debugger?

~~~
kronin
No, I was answering the statement "it looks like an absolute nightmare to
debug".

Amazon's page request and rendering pipeline, I would estimate, is necessary
complexity. Due to the large engineering force and the speed at which they
want to move, it's imperative that the infrastructure support distributed
teams delivering at their own pace while minimizing integration points via
shared repos but instead integrate via defined APIs. This is a fallout of that
need. Do most companies have that need? Probably not.

~~~
quanticle
It's arguably necessary complexity for Amazon. I would argue that the
necessity of the complexity arises from the way that Amazon treats its teams
as individual standalone business units, which prompts teams to treat their
part of the website as a standalone application which communicates with other
parts of the website as if the were third parties. This has advantages and
disadvantages, which have been outlined elsewhere.

However, even assuming that this is necessary complexity for Amazon, it does
not mean that this is necessary complexity for your organization. In fact, I
would argue that this is very likely unnecessary complexity for the vast
majority of organizations. I concur with others in this thread who say that
this framework is the result of an assumption that splitting everything into
tiny components communicating via API is a good idea for user interfaces. The
main problem I have with this approach is that it encourages divergence in
user experience for different parts of the web site or web application. This
is definitely a problem that Amazon has, and it's a factor that should be kept
in mind before moving to a UI pattern that's modeled off microservices.

------
encoderer
I appreciate the skepticism in the comments because this is a level of
complexity that just is not needed in most projects.

This solution adds value when you have an engineering org large enough to have
different teams responsible for different parts of your app that are bundled
into a single experience for the user. For example, on Airbnb, one team might
own the listing details page itself while another team owns the booking form
and flow.

~~~
sghiassy
Fully agree. A monolithic architecture works for most cases but not ALL cases.
Large engineering orgs are one such usecase where the monolithic architecture
starts to become less appropriate.

------
Pamar
I gave a quick look at the article so it's probably my fault - can anyone
explain to me why this are not just a new iteration of the concept of Portlet
(1) which was supposed to totally renovate etc. etc. ...

(1)
[https://en.wikipedia.org/wiki/Java_Portlet_Specification](https://en.wikipedia.org/wiki/Java_Portlet_Specification)

~~~
mrbonner
I had the pleasant of designing and implementing a portlet application back in
2005 - 2006 circa in Java with JSR164 (I may put the wrong JSR here).
Initially, I thought portlet concept was very cool and could be a game
changer. After a year or so working with it, my opinion changed: it was so
convoluted, needlessly. If the goal is to shift the rendering responsibility
to the portlet service owner then you could have used client side rendering
with AJaX as well (remember AJAX?)

In the end, I think what really killed the portlet development is the
complication it causes when you have to maintain states among the portlets.

------
mfontani
Server-side Includes or Edge-side includes, which would include either
statically generated (but routinely updated) or dynamically generated (but
cached for a short while) assets work just as well if not better, but they're
"old" technologies, I guess?

------
seotut2
> The best solution I’ve seen is the Single-SPA “meta framework” to combine
> multiple frameworks on the same page without refreshing the page (see this
> demo that combines React, Vue, Angular 1, Angular 2, etc).

I have very little front-end experience (most of the web dev work I've done
was hand-written javascript). But having the overhead of a big, comprehensive
framework such as React, Angualar already seems like an overkill to me. But
having several such frameworks on the same page seems outrageous, it cannot be
considered good engineering. Where are the engineering good practices of
efficiency, craftsmanship etc?

~~~
bunderbunder
I'm even thinking about the human issues here. If you've got different teams
using different technologies, over time you're going to end up with a tangled,
poorly standardized codebase where the same problem is solved 6 different ways
in 6 different places, and people are afraid to make changes because it's hard
to predict their impact.

I have had the pleasure of working at a microservices shop that had everything
working very, very well. The system was a pleasure to work on, development was
easy, the operations team was more in control than anywhere else. But I think
they accomplished it by unilaterally banning a lot of the things that people
think microservices will let them do. Only two programming languages were
allowed (a low-level one for the most performance-critical stuff, and a high-
level one for the rest), only one flavor of database was allowed,
communication protocol changes and any new 3rd party libraries had to be
approved by a Star Chamber tribunal that basically said no to everything,
lines of communication were strictly controlled (viz., none of this "everyone
talks to everyone else through Kafka"), etc. etc.

It was glorious. It really was. Easiest codebase to work in ever. Did I get to
use my favorite languages or libraries? Nope. Was that holding the company
back? Double nope.

------
sghiassy
You would never start out building a website with microservices. They have all
the downsides people have already commented on.

But are people taking into consideration team/employee size?

If you have 100+ engineers working on a site, in different countries with
different managers and different leaders with different product goals. Then
the microservice architecture becomes a necessary evil.

~~~
sghiassy
In my experience I’ve seen good productivity out of a monolithic architecture
up to 50 developers. Have others seen the monolithic architecture scale
higher?

~~~
NicoJuicy
Google?

~~~
sghiassy
They have a monorepo - not monolithic app.

~~~
taeric
I think the expectation is that the app is relatively monolithic, as well. If
you can force everyone into a single repository, why not force them to a
single architecture to push data in?

------
mscasts
What is the benefits of doing this? Micro-service evangelists never care to
explain that.

They link to another blog article that say:

> The monolithic approach doesn’t work for larger web apps

> Having a monolithic approach to a large front-end app becomes unwieldly.

But in my opinion breaking up the frontend (or backend for that matter) they
way that they say you should is much more "unwieldly".

Seriously, is there any benefits at all? Job security?

~~~
jf-
At some point in the development of a large app you run into irreducible
complexity. The logic and moving parts are just necessarily complicated and
nobody is going to fully understand the system. It doesn’t matter what
architecture you use, hard is hard. I think people tend to forget this and
build a house of cards trying in vain to correct it.

~~~
tabtab
Okay, but there are a lot of ways to split up & scale projects and teams
besides microservices. What's needed is a guide for scaling that considers all
the common options and their tradeoffs, and how to measure those tradeoffs
against your own shop.

------
revskill
The hardest part is, again, client-side assets fetching/caching. The
architecture seems scalable for large projects. It's hard but will be easier
if frontend frameworks go to this direction.

