| 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. |