I'm really interested to know how server side API's internally handle overreaching problems and performance.
Client side developers in my current workplace always ask for huge nested objects. We're having a tough time regarding performance as responses are sometimes 6-7 levels of nested objects.
That means a ton of database queries. How does everybody else manage this?
you need to denormalize your database so you can just query for those particular objects without a bunch of joins. Put a limit on nesting, but honestly 6-7 levels doesn't sound that bad.
`jsonb` functions in Postgresql can build nested objects in a single select statement. Combine that with proper joins and functional indices and there shouldn't be a problem.
First query gets the first 100 items, the second query gets the nested associations for those 100 (assuming you couldn't batch it into the first query), the third gets the nested associations for the second's, and so forth. One query for each entity category?
GraphQL is an incremental improvement over REST. The next big thing will be REST over WebSockets with single-field granularity and real-time subscriptions for field value changes.
Having played around with building exactly that, the conclusion I came to is that REST is nice for not having the additional setup step of establishing a websocket connection as well as having the considerably better support for simultaneous http requests over rebuilding that part of the networking stack once again and layering it on top of everything else.
For real-time subscriptions though, websockets (pardon my grammar) are wonderful. Hence why all the above will probably be ignored as they become a trend and people at large learn the sensible limits of what to use them for.
That might look more like graphQL over websockets with realtimes updates. Somebody told me about an already-existing GraphQL with real-time push updates ready-made for integrating with the front-end framework, wish I knew the name of whatever this was, but maybe somebody will chime in.
Not sure how anything is RESTful anymore once it's over websockets. The whole point of REST is it's a perfection of HTTP, and the whole point of HTTP is it's the slowest, most awkward networking protocol ever devised made to pander to the browser's flaccid capabilities.
One problem with GraphQL is that there can some overlap between the results of different queries so it can be wasteful. Also access control is more difficult because a GraphQL query might reference multiple different data types which have different access control rules (a user may only be allowed to see part of the query result) - So it makes access control a lot more complicated.
Facebook has a solution for over-fetching, which they call dataloader.
As for the access control problem: it's easily solved with existing features of GraphQL. GraphQL exposes a user context which can be referenced on a per-property basis and thus used to check the permissions of the user.
Those aren't trivial problems to solve in a traditional REST framework either.
In GraphQL, having one whole query delivered upfront means the server can do some clever query-planning and app-level caching to efficiently fetch its required data. REST endpoints can't do that, since the queries will be spread across multiple network requests.
Why doesn't GraphQL just define semantics over what is JSON syntactically so existing tools and parsers are sufficient? It's already so close to JSON, why use parens and strings containing emedded JSON? E.g., instead of:
{
"query": "repository(owner:\"zapier\", name:\"transformer\") {
id
description
}"
}
> GraphQL does not require a specific serialization format. However, clients should use a serialization format that supports the major primitives in the GraphQL response.
The section of the document you refer to is regarding the response, not the query-language itself.
From the document: "A GraphQL document is defined as a syntactic grammar" -- therefore GraphGL has a (one) preferred syntactic embodiment. The document goes on (in A
BNF style) to define the syntax of the language.
The language defined here is very close, but not quite, JSON - if it were JSON, they could have defined the semantics of GraphQL based on its structure (which could be surfaced also in XML, etc.) rather than defining any surface/syntactic form at all.
If this domain specific language had a huge value-add over plain JSON, it would be another matter, but the notational convenience is small given the all the tooling that you lose by not having be in a standard format.
They have other bigger problems, they are still trapped in Stone Age with XML everwhere (like SOAP), and not nice XML but very obscure usage and memory dumps inside of XML and what not - very ugly mess, often on purpose to keep their formats hard to implement in competitive products.
Client side developers in my current workplace always ask for huge nested objects. We're having a tough time regarding performance as responses are sometimes 6-7 levels of nested objects.
That means a ton of database queries. How does everybody else manage this?