5 ms·

Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL

246 points by wawhal 8y ago

tango12 8y ago
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 :)
- michaelmior 8y ago
  I haven't really ventured into GraphQL land yet, but this looks awesome!
- randall 8y ago
  really great!
homero 8y ago
I'm interested in trying it with yelp https://www.yelp.com/developers/graphql/guides/intro https://www.yelp.com/developers/graphql/guides/intro
- alberteinstein 8y ago
  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
brian_herman 8y ago
Man I wish I worked on an application that needed graphql :....
- boubiyeah 8y ago
  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.
  - thosakwe 8y ago
    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...
    - boubiyeah 8y ago
      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.
peterjmag 8y ago
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.
danr4 8y ago
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.
nojvek 8y ago
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.
- tango12 8y ago
  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-graphql-d29f20cc97d2 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.
  - viraptor 8y ago
    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.
- ericcholis 8y ago
  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.
jaequery 8y ago
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.

246 points by wawhal 8y ago

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

michaelmior 8y ago
I haven't really ventured into GraphQL land yet, but this looks awesome!
randall 8y ago
really great!

homero 8y ago

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

alberteinstein 8y ago
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

brian_herman 8y ago

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

boubiyeah 8y ago
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.
- thosakwe 8y ago
  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...
  - boubiyeah 8y ago
    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.

peterjmag 8y ago

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.

danr4 8y ago

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.

nojvek 8y ago

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.

tango12 8y ago
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-graphql-d29f20cc97d2 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.
- viraptor 8y ago
  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.
ericcholis 8y ago
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.

jaequery 8y ago

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.