Front-End Microservices

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.

I literally lolled when I read the title of this post.

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.

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.

That was my thought as well. This looks like client-side portlets as a pattern without ties to a particular technology framework. I'm not sure that is a great idea as a prescriptive way to design most things, but maybe it is a good conceptual way of understanding some fairly common designs out there (eg, Amazon.com).

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.

The issue also becomes scope pollution. When you load multiple frameworks on the same page, you need something like iframes, or shadow dom to get isolation.

Typically modern JS dependencies are pretty small compressed and gzipped. Especially if there is some mechanism for deduping the dependencies across (ui-microservices).

I think when web-components/shadow dom is finally ready we will see this type of pattern a lot more. Right now because of scope conflicts this becomes a little difficult.

It's like we want the isolation of iframes, where the content lives within the same document flow as the rest of the document.

I work at an enterprise where we have several different applications. But we have a universal header and footer component. Right now it is a nasty mashup of jquery and other js libraries that just get's pasted into everyone's app without any isolation. It would be great if we could have a shadow dom node that isolates something like a small vue or react app from the rest of the application.

Right now I think the only way for this to work is to coallesce around a single framework.

When it comes to download size of the frameworks, if we had scope isolation as in with shadow dom/web components, then we could actually utilize CDN's more frequently. Think a CDN for web components, where chances are that slider element you add to your page has already been downloaded. To avoid downloading the wrong file, we have subresource integrity attributes in HTML now too https://developer.mozilla.org/en-US/docs/Web/Security/Subres....

So if people started fetching resources from a cdn by default, it's possible 90% of resources have already been downloaded by the client before they even reach the site.

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?

This is purely anecdotal, but I feel like developers who have worked on monoliths with terrible teams tend to fall in love with the microservices approach because as long as the endpoint is stable, it doesn't matter what's going on underneath the hood. On the other hand, developers who have worked on microservices with good teams tend to think that microservices are too complex and unwieldy.

I work in finance and we have a similar setup. We have a platform type of app and many different teams working on different products. Each team is responsible for its own part, from JS web components to the Java backend micro services. There are of course teams responsible for building the portal out of the many components, orchestrating the backend of microservices, etc. It does allow teams to work and release independently.

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.