I've used GraphQL professionally and felt it was great... if it matches your use case. Basically, if your data comprises various different types of entities which relate to each other, and clients are likely to want to pull back data on related entities ("give me these Xs and all the Ys which relate to them"), then GraphQL might make sense.
If there is any significant latency in accessing your backing data store, as is usually the case with a SQL database, then care is needed when implementing your GraphQL server. Naive implementations will have the N+1 problem (or the "N²+N+1" problem, etc) and will be slow.
I haven't found a GraphQL server library which I like, so I implemented my own. (I found an MIT-licensed query parser, which saved some work.)
It is designed to make no more than one SQL query for each branch node in the GraphQL query AST (assuming that each type of entity is stored in a single table). Running in production for a while now, works great, fast, was fun to write.
If there is any significant latency in accessing your backing data store, as is usually the case with a SQL database, then care is needed when implementing your GraphQL server. Naive implementations will have the N+1 problem (or the "N²+N+1" problem, etc) and will be slow.
I haven't found a GraphQL server library which I like, so I implemented my own. (I found an MIT-licensed query parser, which saved some work.)
It is designed to make no more than one SQL query for each branch node in the GraphQL query AST (assuming that each type of entity is stored in a single table). Running in production for a while now, works great, fast, was fun to write.