Hacker News new | comments | show | ask | jobs | submit login
Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL (github.com)
246 points by wawhal 70 days ago | hide | past | web | favorite | 20 comments



To be honest, I find graphql syntax really weird. What you get back is json, why not make the query language json itself? So all the existing json processing tools on the frontend just work.

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.


You don’t have to get back JSON. My server allows EDN and YML as well as json. Also JSON as the query language would involve far more boilerplate and is ultimately a machine language. How does JSON validate that a string is an ID and not a date or a breed of dog? It doesn’t. You need something to parse and check your JSON as well.

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.


I think that people might be trying to solve REST problems with GraphQL. GraphQL's strength lies in the query, not the result. Returning JSON from a simple REST endpoint was never the issue. In fact, I think the argument could be made that GraphQL serves best as the ORM layer between multiple front-ends (A React/Angular website, iOS app, Android App, and Electron desktop). Rather than rely on different ORM implementations on each client, abstract the responsibility to the GraphQL layer. REST doesn't really serve that particular role. But, like anything, we have to ask ourselves if we actually need it.


> To be honest, I find graphql syntax really weird. What you get back is json, why not make the query language json itself? So all the existing json processing tools on the frontend just work.

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.


> why not make the query language json itself?

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.


There are a few query builders on github that let you build objects with more typical js logic. We hacked on one for our needs, to avoid concating strings.

We started with this older fork, and have customized/extended it.

https://github.com/wix-playground/graphql-query-builder


Sorry for the shameless plug, but I wrote this blogpost talking about something very similar: https://blog.hasura.io/why-not-use-a-json-dsl-instead-of-gra...

The main edge over REST I think, is schema introspection and consequent community tooling.


I'm not sure how the need for graphql follows from the ideas/solutions. You could have graphjson, which enforces publishing a schema in the standard and forces a structure which allows easy validation. Graphql can be as "wrong" as json. If I write `query { query { query { foo`, it's not any more correct than `{"query": {"query": {"query": "foo"}}}`, but at least I've got existing tools to format the second one and generalise the inner fragments between multiple queries.


Hi HN. We built this when we realised we needed a few nifty bash scripts that need to talk to a GraphQL endpoint, especially piping subscription events to run a bash command.

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 :)


I haven't really ventured into GraphQL land yet, but this looks awesome!


really great!


This is awesome! I particularly like being able to spin up a local instance of GraphiQL against any endpoint (with auth headers and everything). I tried it with GitHub's GraphQL API, and it took me less than a minute to get going.


that Hasura company has really been cranking up dev tools lately. Seems there are some serious brains behind the company. I hope you'll find the equivalent business people to keep you going.


Man I wish I worked on an application that needed graphql :....


I don't know if this was ironic or not but it made me chuckle.

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'm very curious as to where you got that statistic.

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...


It's a made up statistic.

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.


I'm interested in trying it with yelp https://www.yelp.com/developers/graphql/guides/intro


One of the authors here: You can open GraphiQL on any GraphQL endpoint using graphqurl:

  gq https://api.yelp.com/v3/graphql -H "Authorization: Bearer ACCESS_TOKEN" -H "Content-Type: application/graphql" -i


CLI looks neat, but these apps really require things like saved queries to be really useful. I'm pretty happy with using Insomnia app for Graphql / REST so far.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: