The problem only arises when you have to worry about persistent state. As soon as you have to worry about that, you have to think about backups, replicas, disaster recovery drills and so on. It is much easier to solve for that can of worms for one system than three.
Typical production architecture would look like
- frontend only ever sees an opaque session cookie
- bff stores the access token against session and attaches it when calling backend services
Yes, storing JWTs directly in the frontend client is a bad idea but surely there is a better way of communicating that than "JWT is a scam and your app doesn't need it".
> RS256 verification is in the same order of magnitude as a Redis lookup
But the point is that the verification is CPU bound and local to the service - which means that it is horizontally scalable.
Almost every OAuth2 service out there does exactly that: access token for client/bff, refresh token in HttpOnly cookie.
It’s a lot of work to get it right in SSR environments, since both the bff and the frontend need to be able to refresh the access token (preferably transparently during an in-flight request). Even then, access tokens really should expire within a minute or two, not hours or days.
> it starts by raising this question, then argues that it’s kind of a cheap and meaningless punch-down.
The cheap and meaningless punch-down in the article is the vibecoding accusation. The question in the title is actually their main line of attack against that accusation, all the way to the end.
>> QED
So.
Where are the vibecoded Photoshops?
WHERE IS THE THREAT YOU MADE UP TO ATTACK ME?
>>I'm waiting.
I find it hilarious that so many people are finding it so difficult to grasp even the general line of argument of the article despite trying earnestly.
Do they really? Do you genuinely that most people asking the "Where Are the Vibecoded Photoshops?" question are those who don't understand that "Level 2 and 3 activities" were the real bottleneck or are they trying to explain that to people who don't and are unreasonably expecting a 10x productivity boost out of them?
At least you know it wasn’t written by AI… maybe it was left in a draft state because the author disliked the idea of being accused of writing it with AI
That makes it better? That's what bugs me about the anti-AI sentiment. I'm supposed to want to read worse, more poorly written work (like said article) because it has a human touch to it? Yes it would be great if everyone had perfect writing skills, but we're all human, so we don't. If someone uses an LLM to help them get their point across so it's easier to understand where they're coming from, why penalize them for it?
This is the first time in my life I have ever felt the need of an LLM to understand an article. Even after understanding the overall gist of the article (thanks ChatGPT!), I still can't make head or tail of many sentences and find many questionable choices made in the way the article was structured.
e.g.
>And the accusers never want to address that, because addressing it means admitting the accusation doesn't hold up.
This is the first sentence that introduces the "accuse" word in the article without establishing what the accusation is, who the accusers are or why should the accuser be worried about their claim being spectacularly successful (zero counterexamples). The last part is still not clear to me at all.
Then the article makes a bunch of unestablished claims to the point of becoming straight up ad hominem. No, the senior developers of the world are not asking this question because they don't understand that the requirement gathering, architecting and decision making (level 2 and 3 activities in the nomenclature of the article) - but precisely because of it. Senior developers world over are being pressured into unreasonable expectations around delivery speed by CEOs and other management types. The entire point of "Where Are the Vibecoded Photoshops?" is to hopefully be able to communicate to these people that the bottleneck hasn't moved, so to expect 10x increase in delivery is entirely unreasonable.