Learn GraphQL by querying JSON(graphql.college) |
Learn GraphQL by querying JSON(graphql.college) |
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!
One of the nicest things of GraphQL is the type system indeed. You can use tools like https://www.prisma.io/, which generates a GraphQL backend based on your SQL database.
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.
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.
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."
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. 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!
Pretty good deal.
I think you're commenting on GraphQL vs REST itself, and I don't disagree with what you're saying. Your comment, however, seems disconnected from what I attempted to express in the comment that you replied to. My comment was probably not clear, so I'll try to explain:
My comment is about the tooling and its effects on my workflow, which is mostly orthogonal to static vs dynamic typing. Specifically, I'm expressing a preference for simple tools over special-purpose tools. It was very common for me to test REST APIs with curl and share curl commands on team chat that others could copy/paste to reproduce something. SOAP and GraphQL tend to encourage the use of specialized tools, which adds friction to this kind of workflow (which happens on a daily basis). In fact, what I've seen since adopting GraphQL is people sharing screenshots from their IDE. It's in that respect that working with GraphQL reminds me a lot of working with SOAP.
That said, I don't think GraphQL is as bad as SOAP in this respect. I can still use curl to test out GraphQL APIs. It's just a bit awkward and takes longer to construct the command. I don't remember ever doing that with SOAP, but it's also been a long time since I've used a SOAP API.
Returning to your analogy to static vs dynamic typing, I completely agree about static typing helping manage complexity [1], but it doesn't dictate which tool I use. I can write C programs in vim or I can write them in XCode, Visual Studio, or some other IDE. I prefer vim. GraphQL and SOAP feel like using a language that almost forces me to use an IDE.
[1] Static vs dynamic typing isn't the whole story, though. There's also strong vs weak typing. Haskell and C are both statically typed, but Haskell is strongly typed whereas C is usually considered weakly typed. Strong typing helps manage complexity compared to weak typing.
It's a real game-changer.