Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL
1–10 of 21 posts
Re: Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL
#2We 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 :)
Re: Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL
#3Hi 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 :)
Re: Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL
#4Re: Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL
#5I'm interested in trying it with yelp https://www.yelp.com/developers/graphql/guides/intro
gq https://api.yelp.com/v3/graphql -H "Authorization: Bearer ACCESS_TOKEN" -H "Content-Type: application/graphql" -iRe: Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL
#6Re: Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL
#7Re: Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL
#8Re: Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL
#9With 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.
Re: Show HN: Curl for GraphQL with autocomplete, subscriptions and GraphiQL
#10To 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 every…
The main edge over REST I think, is schema introspection and consequent community tooling.