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?
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.
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.
Subscriptions already exist: https://dev-blog.apollodata.com/graphql-subscriptions-in-apo...
https://www.graph.cool/docs/tutorials/worldchat-subscription...
No, it's a huge step backwards into RPC.
{
"query": "repository(owner:\"zapier\", name:\"transformer\") {
id
description
}"
}
{
"query": {target: "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.
JSON is preferred, but not required.
[1] eg. http://ogp.me/