3 ms·

How do you guys bridge the abstraction gap/wall between resolvers to prevent N+1 queries? I have the suspicion that GraphQL is great for exposing a really gener

How do you guys bridge the abstraction gap/wall between resolvers to prevent N+1 queries? I have the suspicion that GraphQL is great for exposing a really generic API, useful when you have no idea what shape the front end will take (how often is that?). But it comes at a heavy price; genericity is always the opposite of specialization. And optimization can only occur during specialization. Having worked with it for a bit over a year now, it really feels like GraphQL is just a different protocol for writing the same old REST CRUD, while introducing a huge framework with lots of annoying magic and language level reflection that isn't amendable to extension or modification according to the needs of the developers. Is that all worth it, just to reduce the amount of HTTP requests? Is it that much of a sacrilege to add specialized REST HTTP endpoints to remedy that otherwise?

mewpmewp2 2y ago
Also if it's really the problem with HTTP Requests, you could still technically abstract multiple REST API/RPC calls into a single HTTP Request.
strken 2y ago
Putting a dataloader in front of batch APIs usually works okay. You end up with round trips but they're 1+1 and inside the data centre. I've used AST traversal to compute joins a couple of fields ahead + custom resolvers that only load their data if it wasn't loaded by the parent, but I don't think that's necessary to get decent performance and I wouldn't do it again unless there was a real business need. I agree that genericity is often the opposite of specialisation. I disagree that it's a heavy price. REST is pretty general. To my mind specialist APIs are things like streaming video, file uploads, anything that relies on caching in an intermediate layer, etc. and these are all examples of where you'd follow the established standards and add some RESTful routes/services. I don't think it's sacrilege to upload files in a different way to how you load your user dashboard or your interface for editing project permissions.

mewpmewp2 2y ago

Also if it's really the problem with HTTP Requests, you could still technically abstract multiple REST API/RPC calls into a single HTTP Request.

strken 2y ago

Putting a dataloader in front of batch APIs usually works okay. You end up with round trips but they're 1+1 and inside the data centre. I've used AST traversal to compute joins a couple of fields ahead + custom resolvers that only load their data if it wasn't loaded by the parent, but I don't think that's necessary to get decent performance and I wouldn't do it again unless there was a real business need. I agree that genericity is often the opposite of specialisation. I disagree that it's a heavy price. REST is pretty general. To my mind specialist APIs are things like streaming video, file uploads, anything that relies on caching in an intermediate layer, etc. and these are all examples of where you'd follow the established standards and add some RESTful routes/services. I don't think it's sacrilege to upload files in a different way to how you load your user dashboard or your interface for editing project permissions.