@NEETzsche@roboneko@alex@josh you brought up 1kb payloads like they don't matter. they do matter, it has nothing to do with string parsing performance, it has to do with the db calls to generate that 1kb payload.
@NEETzsche@roboneko@alex@josh if you want to talk about protocols, graphql is leaner and what I've been trying to tell you but you dismiss it even if it saves a ton of db calls
@NEETzsche@roboneko@alex@josh dude you have to be trolling. javascript is fast enough to do api calls. what's not fast is doing a bunch of relational table joins that you wouldn't have to do otherwise
@NEETzsche@roboneko@alex@josh >So you're saying that we need to start getting rid of databases so that we can reduce the system resource requirements for running a server that handles "type shit in, other people see it" back to what they were in the 1990s? ok you're just trolling me
@NEETzsche@roboneko@alex@josh you're deliberating ignoring the question of scale. it's pretty easy to do "type shit in, other people can see it" when you're dealing with a few hundred network requests
@NEETzsche@alex@josh due to typescript and graphql, if I code a graphql query that's like `{ users { name }` which is effectively the same as the sql query `select name from users` and the name column doesn't exist on my database my linter will bitch at me that the field is invalid.
I basically get to write database calls on my frontend and get them validated like sql ones directly in a sql command line
@alex@feld@eriner@josh >Can you make Pong in Postgres triggers? lmfao you know, if you used sql queries for direction movements I think you could? you just track the movements in rows and the function calls would be like `perform next_tick()` and `perform move_paddle_up()`