Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL
github.com
github.com
With the weird syntax, now you need a parser and checker, and you need to write some boilerplate for doing mutation syntax.
There’s a reason why everyone and their dog invented ORMs. So you could live in an object world and everything would just work. SQL translation magic would be just an abstraction.
GraphQl has some nice things, I.e you only fetch what you need, and the fact that that it exposes a service as a graph. However I’m not sold that it’s a big improvement over simple REST.
The main edge over REST I think, is schema introspection and consequent community tooling.
Netflix's JSONGraph is that. In my opinion it's… kinda shitty to write requests for, it's noisier than graphql queries and offers little in the way of benefits.
> GraphQl has some nice things, I.e you only fetch what you need, and the fact that that it exposes a service as a graph. However I’m not sold that it’s a big improvement over simple REST.
Simple as in trivial? No if you're only exposing an API to fetch an integer over the network it's not an improvement. If you're fetching complex data structures however, most RPC-over-HTTP (as I assume you don't actually mean REST-as-in-what-Fielding-defined) don't do the distance. They're add-hoc, less convenient to mess with (few have explorer) and commonly ill-defined.
As for boilerplate for writing mutations... why do you say that’s needed? My clients’ queries and mutations are static and parameterized with variables, much like parameterized SQL queries. Just reuse the query/mutation and pass in a different map of parameters when you perform similar actions.
As for ORMs, well sure. We don’t use SQL but datomic is one of the DBs we use, and some of its schema is translated into the graphql schema. There’s also salesforce, elasticsearch, postgis, and existing pre-graphql APIs. The server handles the logic for joining the right results at the right points in the query. You’re seriously downplaying how nice it is for the client to not have to worry about client-side joins and getting exactly what they need. I can’t tell you how many times I’ve seen bugs in the wild because the client is trying to ask for an object out of a rest api using a ID of undefined or null because they’re in the middle of a join and thought they had data in hand. The schema prevents them from trying to ask for invalid relationships. And can make guarantees about availability. I also make available meta information such as result counts and page information so they know when to stop walking.
It’s usually pretty straightforward to reuse resolvers to meet the client’s ask, so if one client needs cars sold by dealership and another needs cars sold by state and another needs cars sold by salesperson, I can choose to support it all in the same handler by providing arguments they can all use, or I can expose it as a nested graph they can walk starting from any of these points.
We started with this older fork, and have customized/extended it.
Simplifying a bit: a JSON document is a set of keys and values. a GraphQL document is a set of keys asking for values.
If the query language was JSON, what would be used for values? Yeah, you can work around it but it would be working around what JSON is intended for.
We also use it as a node library from some lambda functions and then while we were at it, we realised a GraphiQL on demand to test a GraphQL endpoint would be nice too :)
Many people actually DO use technologies that are absolutely not required but which bring incidental complexity because it's fun and hot right now.
Seriously, graphQL is perhaps worth considering for maximum 10% of projects out there.
I understand that we programmers are often very resistant to change, but there's nothing inherently wrong with using something new. If someone feels the benefits are worth the learning costs, then they are free to go ahead and use "X" technology...
GraphQL reminds me of the NOSQL movement. Everyone wanted to try one of these systems, even when they were completely broken at the time (e.g mongodb) And yet, most apps will do just fine with a classical SQL DB and all the comfortable features you can use to speed up development at the cost of scalability (transactions, locks, listen/notify, etc). It's just not a pain point most app ever encounter.
Let me rephrase: How many times was the JSON payload bulkiness in the top 3 performance killers of your app? The answer is 0 for me, after developping dozens of apps. Although to be fair, GraphQL is not as extreme as the NoSQL movement at the time, as it's still a valid alternative even for some apps that are not at Facebook/Netflix scale and the very opinionated approach will be a comfort for many people compared to REST. I'm just strongly reacting to the "duh, of course you should use graphQL instead of REST" fad.
gq https://api.yelp.com/v3/graphql -H "Authorization: Bearer ACCESS_TOKEN" -H "Content-Type: application/graphql" -i