What does HackerNews think of graphiql?
GraphiQL & the GraphQL LSP Reference Ecosystem for building browser & IDE tools.
You have this backwards.
https://github.com/graphql/graphql-playground/issues/1366#is...
If you accept that you don't want your web client talking directly to the database, then you need something that will interface with the database. That problem has been around for a while with many different solutions: SOAP, ReST, PouchDB/CouchDB, interface with various cloud services, something completely custom, and many others. GraphQL is just one of the latest solutions to that problem and with it, brings some advantages around flexibility in the API requests and responses. It also makes it easy to stitch together multiple GraphQL APIs. So, by being standardized* you don't need to develop the client code yourself and you gain the ability to pull together APIs from multiple sources to present as a single end-point. The most popular clients also provide caching mechanisms so you don't have to keep whacking the back-end for the same data repeatedly. There's also graphiql [1], which gives you a really nice way to query or modify your data on any GraphQL API, which I've found to be very helpful when learning new APIs.
So far, I've found GraphQL most useful for single page applications where the back-end really doesn't have to do much more than handle DB interactions. If you already have an application up and running with little churn in the API, adopting GraphQL probably wouldn't gain you much. In a greenfield application, I was able to use Hasura to replace a simple Rails CRUD application and that was handy. Hasura also takes care of JWT handling, so I could do my auth with Auth0 and not handle that in Rails either. I think GraphQL solves an interesting part of the serverless puzzle.
Don't get me wrong, GraphQL can be downright frustrating at times. Or at least the popular implementations of it can be. We use Relay at work and while it solves a lot of problems, it introduces many of its own that have cost me hours of frustration. I tried using AWS Amplify on a side project, and having to write new AppSync resolvers with Velocity templates is just not pretty. It really took using Hasura for me to finally be sold on what the GraphQL promise could be (side note: Hasura doesn't support the Relay protocol, so if that's important to you, you'll need to find a different tool).
* -- Standardized is a loose term. There is a GraphQL spec, but it leaves a lot available to implementation details. So, then there are other specs, such as Relay, built on top of that. Or de facto standards based on what the popular clients provide.
Absolutely love graphql as a technology. The pagination and ability to structure a query to pull a lot of data is nice.
As for some of the other comments - it's true you can't just write any query: but you can always add new fields, lists, connections (basically a pagination-friendly list), etc against arbitrary things on the backend. It's your backend, you control what data you serve.
The graphql-python stack is layered like an onion (graphene on top, graphql-core inside). You will probably be doing something like flask-graphql or graphene-django on top of that.
There is a huge negative for python <-> graphql for us, and it's the error system and promises. Perhaps this is what graphql servers in JS are like, but graphql-core hijacks python's error system by wrapping fields in promises.
So graphql-core is acting very very true to graphql's implementation in node: to the point it creating a mountain of breadcrumbs in sentry.
It also overrides the "next" built-in and tries to emulate express-style callbacks. Another thing ported from node into python that doesn't translate well imo.
Aside from that though: graphene has been really speedy, fast to work with. Documentation is getting nicer. The developers on the issue tracker are very nice. And as a general graphql thing: https://github.com/graphql/graphiql is really nice!
And one more graphql thing: It's typed. In a big API, being able to lay out stuff like that goes a long way. We're generating typescript types via schema.graphql output, and response types via relay. In a real big frontend project, it pays off a lot.
I recommend giving graphql a shot.
Instead of that, i'd personally recommend either sticking with your old schema if the change is as superfluous as the one mentioned on the project's README (changing the type of the `userById(id)` field parameter from `String!` to `ID!`), or shamelessly embracing versioning your fields. In the case example case mentioned on the README, that could mean adding a @deprecated directive on the `userById(id: String!)` field, and then adding a new `userByIdV2(id: ID!)`. Users of the new field can alias it on to a friendlier versionless name, like:
query {
user: userByIdV2(id: 123) {
...
}
}
[1] Like Intellij IDEA's graphql plugin https://plugins.jetbrains.com/plugin/8097-js-graphql [2] https://github.com/graphql/graphiql
But I'd love to see an REST-based GraphiQL equivalent to prove this wrong: https://github.com/graphql/graphiql
Forgive me if this sounds hyperbolic, but unless you have unusual or strict requirements, building a new app in 2017 REST-first is most likely a terrible mistake.
Let me clear up some misconceptions I see in almost every HN comment thread on GraphQL:
1. GraphQL isn't more suited to Graph databases. Your data sources can be a mix of relational DB, NoSQL, key value, a REST API, or anything else.
2. n+1 has always been a solved problem in GraphQL thanks to DataLoader[1], a query batching utility which coalesces calls to your data sources from different parts of your app, specifically to avoid n+1.
3. It's unquestionably production-ready, battle-tested, has a real spec and official reference implementation, and it's probably the safest bet you can make at this moment in an industry as fickle as this.
With GraphQL you simply write your schema, define types and relationships, and you’re then able to request data in almost any shape you wish, with very little extra work. This is invaluable during development.
If you have a list of recent comments with author names, and later decide to show an avatar alongside the name, you don’t need to write any extra code on the server. You add an extra line to your query (or component’s fragment) on the client.
The same goes for any field, any relationship, no matter how complex the resulting shape. If you wanted a comment author’s follower’s comments’ likeCounts, you still don’t need to write another line of server code.
This makes it stupidly simple to rapidly prototype new features, try out new layouts, and means you can share a single API endpoint between mobile apps and desktop site without sending useless data to one or both.
There have been many occasions when we simply wouldn't have had the time to implement a feature correctly with REST, particularly when we might not even know what data we'll want until we begin developing the feature and get a feel for how it works.
It doesn't just save server dev time either. On the client side there are libraries like Apollo[2] and Relay which take care of fetching data, caching, normalization, and you should almost certainly use one (I recommend Apollo) unless you have a good reason not to. Writing fetch calls and managing your store manually is just going to be a huge waste of time.
And the spec is more than queries and mutations. It's subscriptions, live queries, and more [3]. Real-time data is a first-class citizen of GraphQL, and the two most popular front-end libraries have official implementations of subscriptions (with live queries in progress).
GraphQL is elegant, has a well-designed official spec, great DX and just plain makes sense. But it's really something you need to try out for yourself (preferably on a real project) to see just how great it is.
If you’re planning to build something new with REST, seriously, reconsider. There's a slightly higher upfront cost to using GraphQL (particularly if you're new to it), but once you settle into it you'll be glad you did.
Useful tools and resources:
- GraphiQL[4] - an incredibly useful tool for running queries on your GraphQL API
- Graph.cool[5] - BaaS for quickly prototyping a GraphQL API
- Apollo Launchpad[6] - Try out GraphQL server code in your browser
[1] https://github.com/facebook/dataloader
[2] https://github.com/apollographql/apollo-client
[3] https://dev-blog.apollodata.com/new-features-in-graphql-batc...
Source code is here: https://github.com/langateam/graphiql.io
Meteor is a full stack. It has no direct relationship(or cannot compare with) GraphQL. Meteor also a realtime framework, but GraphQL does not address realtime aspects (yet).