Hacker News new | ask | show | jobs
by jiggawatts 162 days ago
Ironically posted on Medium, which showed me the text, then blanked the whole screen to replace the text with light grey polyfills, and then showed me the same text again... several seconds later.

That's because Medium is a bunch of APIs and (micro) services, not a monolith like it should be.

Heck, it could be plain static HTML because it's just text for crying out loud!

Instead, it uses a GraphQL query through JSON to obtain the text of the article... that it already sent me in HTML.

Total page weight of 17 MB, of which 6.7 MB is some sort of non-media ("text") document or script.

This is user-hostile architecture astronaut madness, and is so totally normal in the modern internet that nobody even bats and eye when text takes appreciable amounts of time to render on a 6 GHz multi-core computer with 1 Gbps fibre Internet connectivity.

Your customers hate this. Your architects love it because it keeps them employed.

4 comments

> light grey polyfills

Those grey loading placeholders for text are called skeleton loaders BTW, polyfills are libraries used to support newer browser APIs in older browsers and not something you can exactly see on a website (without checking the devtools)

TIL
A simple modern Dotnet monolith with Postgres on a Linux server could deliver a much better end user experience, and it probably would take a lot less server resources than the current mess.
I tried to explain this to a team that eventually lost their customers to competitors who could generate less interesting pages far cheaper per request. Instead they went off on a two year jag trying to cache page sections.

You know a team has lost the architectural plot when their answer for all performance problems is more caching. And once you add caching it’s hard to sell any other sort of improvements because the caching poisons the perf analysis.

Their solution took forever because the system was less deterministic than we even knew. They were starting to wrap it up when I went on a tear cleaning up low level code that was nickel and diming us. By the time they launched they were looking at achieving half of the response time improvement they were looking for, in twice the time they estimated to do so. And they cheated. They making two requests about 10% of the time, which made the p50 time into a lie, because two smaller requests pull down the average but not the cost per page load. But I scooped them and made the slow path faster, undercutting another 25% of their perf improvements.

I ended up doing more to improve the Little’s Law situation in three months of working on it half time than they did in two man years. And still nothing changed. They are now owned by a competitor. That I believe shut down almost all of their services.

Monoliths vs. microservices has nothing to do with server-side rendering vs. GraphQL. Architecturally monolithic Web apps use GraphQL all the time.

I'm not sure why Medium does the weird blanking thing but my guess is that it's because it's deciding whether to let you read the article or instead put up a paywall. There are a lot of SPA sites out there, many of which aren't particularly economical with frontend resources, and they generally don't do that unless they're trying to enforce some kind of paywall or similar.

> Architecturally monolithic Web apps use GraphQL all the time.

Sure, but a significant motivation for using GraphQL is to stitch together a bunch of microservices into a cohesive API for the front end.

My comment about Medium using microservices was just an informed guess, but a good one. They started migrating from a monolith to microservices back in 2018: https://medium.engineering/microservice-architecture-at-medi...

Is it a coincidence that that's around the time frame that I noticed the Medium web site becoming slower than it used to be?

I do in fact think it's pretty unlikely that any performance degradation you observed was directly caused by microservices, as opposed to changes that directly affected the frontend.
I politely disagree. Microservices are the large government bureaucracy of software architecture with similar efficiency outcomes for similar reasons.
Monoliths generally server side render. Server side rendering is fast, consistent and performant, the state of the client won't get into wonky territory since they are a button click away from getting current, known good state from the server.
That’s not a microservice vs monolith thing. That’s a client-side single-page app vs server-side rendering thing. Although, granted, I more often see microservice architectures with single-page apps than with server-side rendering.