4 ms·

Learn GraphQL by querying JSON

96 points by spell-slinger 8y ago

mixedCase 8y ago
CSS is broken in Firefox.
- monkeynotes 8y ago
  HN is a tough crowd.
  - subie 8y ago
    Free cross platform testing. Pretty good deal.
- spell-slinger 8y ago
  Thanks for the heads up! I'll try to fix it now :D
- spell-slinger 8y ago
  Fixed! :D
ht85 8y ago
Errors from parsing the JSON should show up somewhere visible, as of now it looks like nothing happens unless you check the console.
- spell-slinger 8y ago
  Good catch. I actually showed them in a previous version, but now I let Codemirror show JSON errors inline.
crispyporkbites 8y ago
For me GraphQL adds a lot of complexity when setting up the API for only an incremental benefit when querying. Do others feel the same? Or am I missing something?
- nicwolff 8y ago
  If you're using it to make simple queries the benefit over REST is incremental. But you can use it to get in one request all the data it would take your API clients many REST requests to gather, and then the benefit can be dramatic.
- bhldr 8y ago
  It's a pretty great format for rapid prototyping, but very complex and wouldn't deploy it as a public API that needs to be supported for a long time.
  - optimuspaul 8y ago
    Thats what I thought at first as well. But as I started working deeper and using more frameworks (had to write some as well) that made the complexity go away. Adding data sources can be very easy and the frameworks, like Apollo, take care of all the things you had to think about previously. I know that there are of course frameworks that handle cacheing and query routing for REST apis, but the flexibility of GraphQL is unparalleled. I find them to be best suited to backing UI's that may get rethought and reworked every 6mo to a year. As well as for data analytics ad hoc queries. My point is the can be very complex, but they don't have to be. I have a number of them deployed right now that are far more hands off for me than our other APIs.
tapsboy 8y ago
Looks like a low friction way to bring on new team members to GraphQL. However, the tools is either broken or not finished yet. I tried to change posts to books in the JSON tab and I get an error below: "Cannot extend type "Post" because it does not exist in the existing schema."
- spell-slinger 8y ago
  Glad you found it useful! Sorry for the cryptic error. That happens because the two objects in the comments array reference post_id. If you change those keys to book_id everything should work. The algorithm for generating a GraphQL schema from a JSON object could be improved, along with its error handling. I use the algorithm from this repo: https://github.com/marmelab/graphql-schema-from-json https://github.com/marmelab/graphql-schema-from-json. Error messages come from there. I'll work on improving this tool and make it more user friendly. But I think that it is worth sharing it, even at this stage. Cheers!
jaequery 8y ago
i thought Graphql was confusing at first, merely because of their distinction of "Query" and "Mutation". It turns out (which I should've known), "Query" is just like GET requests where you are retrieving information and "Mutation" is like a POST/PUT/PATCH/DELETE requests that can modify the data. After grasping this, Graphql was pretty similar to working with REST and a bit more flexible in how we want the data to be returned. Graphql really does fix the whole "query multiple endpoints to construct a single data" dilemma. Only thing I didn't like about it was the way Graphql schema is to be written in server side, thought it could be a bit more intuitive and simplified . Currently, it can get pretty verbose and breaks the DRY mantra. Would be nice if the Type system can be hooked up with the whatever ORM you are on (Mongoose, AR, Sequel) because you'll be re-mapping the fields to Graphql which can be an overhead for no reason. Also schema is like working with SOAP's WSDL all over again. I used to hate it but it's back with Graphql so I'm trying hard to like it!
- spell-slinger 8y ago
  Glad to know GraphQL clicked with you! One of the nicest things of GraphQL is the type system indeed. You can use tools like https://www.prisma.io/ https://www.prisma.io/, which generates a GraphQL backend based on your SQL database.
- davidcuddeback 8y ago
  > Also schema is like working with SOAP's WSDL all over again. Glad to hear that I'm not the only one who feels that way. I still like using simple tools like curl to try out APIs. It's so much easier to demonstrate an issue to a coworker when you can copy/paste a curl command in email/chat/PR. My (admittedly limited) experience with GraphQL so far has been that it makes this more awkward.
  - vicarrion 8y ago
    This is the static vs dynamic type argument at its heart. When making small apps, dynamic wins out from not having to declare or think too much about types. After some threshold in complexity having static types is much better.

96 points by spell-slinger 8y ago

mixedCase 8y ago

CSS is broken in Firefox.

monkeynotes 8y ago
HN is a tough crowd.
- subie 8y ago
  Free cross platform testing. Pretty good deal.
spell-slinger 8y ago
Thanks for the heads up! I'll try to fix it now :D
spell-slinger 8y ago
Fixed! :D

ht85 8y ago

Errors from parsing the JSON should show up somewhere visible, as of now it looks like nothing happens unless you check the console.

spell-slinger 8y ago
Good catch. I actually showed them in a previous version, but now I let Codemirror show JSON errors inline.

crispyporkbites 8y ago

For me GraphQL adds a lot of complexity when setting up the API for only an incremental benefit when querying. Do others feel the same? Or am I missing something?

nicwolff 8y ago
If you're using it to make simple queries the benefit over REST is incremental. But you can use it to get in one request all the data it would take your API clients many REST requests to gather, and then the benefit can be dramatic.
bhldr 8y ago
It's a pretty great format for rapid prototyping, but very complex and wouldn't deploy it as a public API that needs to be supported for a long time.
- optimuspaul 8y ago
  Thats what I thought at first as well. But as I started working deeper and using more frameworks (had to write some as well) that made the complexity go away. Adding data sources can be very easy and the frameworks, like Apollo, take care of all the things you had to think about previously. I know that there are of course frameworks that handle cacheing and query routing for REST apis, but the flexibility of GraphQL is unparalleled. I find them to be best suited to backing UI's that may get rethought and reworked every 6mo to a year. As well as for data analytics ad hoc queries. My point is the can be very complex, but they don't have to be. I have a number of them deployed right now that are far more hands off for me than our other APIs.

tapsboy 8y ago

Looks like a low friction way to bring on new team members to GraphQL. However, the tools is either broken or not finished yet. I tried to change posts to books in the JSON tab and I get an error below: "Cannot extend type "Post" because it does not exist in the existing schema."

spell-slinger 8y ago
Glad you found it useful! Sorry for the cryptic error. That happens because the two objects in the comments array reference post_id. If you change those keys to book_id everything should work. The algorithm for generating a GraphQL schema from a JSON object could be improved, along with its error handling. I use the algorithm from this repo: https://github.com/marmelab/graphql-schema-from-json https://github.com/marmelab/graphql-schema-from-json. Error messages come from there. I'll work on improving this tool and make it more user friendly. But I think that it is worth sharing it, even at this stage. Cheers!

jaequery 8y ago

i thought Graphql was confusing at first, merely because of their distinction of "Query" and "Mutation". It turns out (which I should've known), "Query" is just like GET requests where you are retrieving information and "Mutation" is like a POST/PUT/PATCH/DELETE requests that can modify the data. After grasping this, Graphql was pretty similar to working with REST and a bit more flexible in how we want the data to be returned. Graphql really does fix the whole "query multiple endpoints to construct a single data" dilemma. Only thing I didn't like about it was the way Graphql schema is to be written in server side, thought it could be a bit more intuitive and simplified . Currently, it can get pretty verbose and breaks the DRY mantra. Would be nice if the Type system can be hooked up with the whatever ORM you are on (Mongoose, AR, Sequel) because you'll be re-mapping the fields to Graphql which can be an overhead for no reason. Also schema is like working with SOAP's WSDL all over again. I used to hate it but it's back with Graphql so I'm trying hard to like it!

spell-slinger 8y ago
Glad to know GraphQL clicked with you! One of the nicest things of GraphQL is the type system indeed. You can use tools like https://www.prisma.io/ https://www.prisma.io/, which generates a GraphQL backend based on your SQL database.
davidcuddeback 8y ago
> Also schema is like working with SOAP's WSDL all over again. Glad to hear that I'm not the only one who feels that way. I still like using simple tools like curl to try out APIs. It's so much easier to demonstrate an issue to a coworker when you can copy/paste a curl command in email/chat/PR. My (admittedly limited) experience with GraphQL so far has been that it makes this more awkward.
- vicarrion 8y ago
  This is the static vs dynamic type argument at its heart. When making small apps, dynamic wins out from not having to declare or think too much about types. After some threshold in complexity having static types is much better.