3 ms·
> you can't use 'negigibly' worse as a defence Absolutely you can when the increase in something (bandwidth) in a system with surplus supply with the trade-off
by tomnipotent 3y ago
> you can't use 'negigibly' worse as a defence
Absolutely you can when the increase in something (bandwidth) in a system with surplus supply with the trade-off of optimizing a more constrained supply (CPU or memory).
> made a crazy SQL select instead of a normal one, which is harder to maintain.
Purely subjective. Myself nor the people I've hired would have a problem maintaining a more complex SQL query using CTE's and JSON serialization than not.
> it's worse performance
I cannot imagine that's the case in the context we've been discussing. An RDBMS duplicating JSON output of tuples multiple times in a single transaction is not particularly expensive compared to the alternative.
- 411111111111111 3y agoThe funnest part of outputting JSON from the query is that your API now basically becomes a RPC, as you don't have to do any marshalling/deserialization before returning the response with Content-Type application/json Response times are really fast like that, as you probably already know. Always fun to see <10ms round trips in the browser network tab on some requests Also no worry about n+1 queries, as they're fundamentally impossible to do like that
- password4321 3y agoI've long wondered if there would be any performance advantage for an API server to zero-copy the DB response to the browser, deserializing from the DB wire protocol on the front end. Or perhaps sending DB query results directly from DB server to browser, with the API server just initializing and securing. Thanks for pointing out how JSON from the DB is another option for moving a bit of processing elsewhere in the stack.
- tomnipotent 3y agoYou've basically described Firebase and its archetype of database.
- vbezhenar 3y agoTLS everywhere makes the whole point of zero copying obsolete. Encryption eats so much CPU that copying data around does not change anything.
- 411111111111111 3y agoIt does add a few ms, but you're overstating it. For LAN traffic, it's usually 5-8ms last time I checked on my servers.
- mattmanser 3y agoThat not what we're talking about though, we're talking about aggregating the the result of a subselect to reduce the throughput of a SQL query. I'm just pointing out it doesn't achieve that.
- mattmanser 3y agoIt's not subjective, it's.objective. This solution for tuples is objectively worse in every way, throughout, network bandwidth, code complexity, maintainability, error likeliness. You're just clearly someone who can't admit when they're wrong.
- tomnipotent 3y ago> it's.objective. Prove it. > You're just clearly someone who can't admit when they're wrong You don't have a good technical argument so you jump to ad-hominem's?
- remram 3y agoThey've presented plenty of drawbacks, which you've dismissed as "it's not that bad", while not presenting any benefit.
- tomnipotent 3y agoI've presented the bandwidth vs. memory and CPU trade-off, was that not obvious? Not to mention reduced network round trips, and less overhead on transaction management. If the biggest issue in my product is JSON deser, I'd be a happy camper.
- remram 3y agoBandwidth and memory are probably both worse, JSON adds overhead. Round trip latency only happens if you wait for the results of one query to send the other.
- xupybd 3y ago>You're just clearly someone who can't admit when they're wrong. I suggest avoiding statements like this. Yes they help vent your frustrations but they destroy the otherwise constructive and interesting debate the two of you were having.