Ask HN: Were you happy moving your API from REST to GraphQL?

GraphQL is great for the frontend, but moving to GraphQL involves both people and tech issues. Common mistakes made when using new technologies are made all over again.

* Watch out for bad implementation of the GraphQL API (this will definitely result in bad performance).

* Design the GraphQL schema that you want the user to see/perceive. Not every object or field in your database needs to be exposed via the API the way it is.

My workplace is currently moving a huge monolith into a bunch of manageable components. Each of these components has its own GraphQL endpoint. Using schema-stitching, these are being stitched together into one endpoint for API users.

As a result of our codebase, we've tried GraphQL in:

* Ruby (graphql-ruby) - WATCHOUT Relay arguments for connection fields are not exposed to the library user. So basically you have to implement your own Relay-compliant stuff if you need access to the pagination arguments from Relay. Also, documentation is broken.

* Python (graphene) - We've had no issues so far. We worked around it.

* Node.js (Apollo GraphQL) - OH MY BUTTERFLIES. So far, this is the ONLY library I have come across that is polished and has plenty of documentation.

* Elixir (Absinthe) - My coworker worked on this part. He did not complain. So I'm assuming he had no issues.

The "Learn * in a day" joke applies to GraphQL. As simple as GraphQL looks for the client-side, it is beast of a job to build a GraphQL backend that is optimized for production.

Servers-side implementation of GraphQL is not very well documented apart from hello-worldly examples. Most of the knowledge found online is about client-side usage.

Due to poor documentation/examples provided, ramping up people with GraphQL is hard. Most first iterations I've had to review were slower than our REST APIs because of unoptimized code. Sitting down for a few minutes solves that problem.

To ramp up people at work place, I ended up having to do this:

* Ask people to use the GitHub v4 API to checkout GraphQL.

* Make them build a GraphQL server for a blog app.

* Dive straight into whatever feature/API they would build.

* Review their work a few dozen times and show them optimization tricks.

My most valuable lesson: When in doubt, dig into the source of these libraries.

>we were spending a lot of client time fetching deep trees through resource links

>it solved a lot of the administrative and philosophical headaches

>considerably reduced the number of connections

>considerably reduced wasted data

>made our client code so much simpler through easily grokked queries

I feel that grandparent does contain information which might be valuable for adoption.

Do you have a kotlin graphql library you'd recommend. I just started working on Kotlin with GraphQLJava. I saw graphql-kotlin, but that appears to have been updated like a year ago. I've been using graphql-spqr. Mixing kotlin and java in my projects, to get around the annotation bug.

I do agree on the noise and lack of tutorials. I'm getting ready to present on a GraphQL option. We don't want to use javascript. The tutorials for java are a bit cumbersome.

Btw I'm really liking apollo.

Who says GraphQL is not RESTful, though?

You have resources represented as a graph and you're asking for the state (in some representation -- probably JSON, but maybe protobuf, etc), just in a more expressive and deeper way than a simple HTTP Get with a single URL can express.

Nothing about REST ever said that a resource locator had to be a URL, or that a single resource can't represent a collection of resources.

That's all GraphQL does, IMO. It lets you more flexibly and expressively ask for stat of a collection of resources.

I’ve only heard positives about Absinthe for Elixir fwiw.