Because simplicity is hard and often the result of careful thought. Anybody can keep piling pile of shit on top of pile of shit which is why that sort of code is so common in our industry.
> but it's irritating to perform a full row-to-column conversion through an inefficient, non-batched API in order to get the data through JDBC and into TMD
[...]
> In the last two years, DuckDB improved a lot. Importantly, the C interface now provides a batched system for both inserts and querying, which enables processing very large joins
That's why. Basically JDBC doesn't offer the batched APIs needed to get the same performance.
Pretty sure that is entirely an unfair comparison. You don't need a connection per thread either. It is common to have web servers handles thousands of requests per second with a connection pool size of 20. As long as the handler threads borrow a connection for only a little time and block waiting for a connection while other threads are doing their thing, it works out fine.
There is absolutely no logical reason why database pool sizing could be a reason for preferring fibers over threads.
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?
reply