
Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL - wawhal
https://github.com/hasura/graphqurl
======
nojvek
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
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...](https://blog.hasura.io/why-not-use-a-json-dsl-instead-of-
graphql-d29f20cc97d2)

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

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

------
tango12
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
I haven't really ventured into GraphQL land yet, but this looks awesome!

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

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

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

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

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

