The biggest challenge I faced during the GraphQLAPIs was auth and implemented REST endpoints for that.

And later on, considering the users of GraphQL API, there is too many complexities in keeping the gql query sane, it's too large.

To optimize the size of query, I started using the Fragments but there is no consolidated way to share Fragments in whole codebase.

I've used Graphql with my python and django apps there is a very nice library named graphene for python and django which handles almost everything the only not really straight forward thing is adding custom filtering to queries which I handled with django-filter, so far seems they had done a great job with python packages and you can just dive in using graphql in your python apps with a little bit of documentation reading.

GraphQL is sometimes represented as a revolutionary way of API comprehension. This article can be useful and informative GraphQL Overview: a Simple Introduction for Any Developer

At Looop.co we're using decapi on top of objection.js database models. Our DB is Postgre. Sure we could have used Prisma instead, but objection.js allows us to drop down to war SQL queries whenever we feel like it. That's a feature we'd definitely miss if we were to use Prisma/Hasura or some similar GQL API framework.

Our biggest pain-point is the client side. We use apollo-client, but we have multiple schemas and we haven't yet figured out a way to generate our types from our schemas. It should be easy with a single schema, but we have 3, so for now we're just writing the FE interfaces for our GQL queries by hand.

Built an entire application using Apollo GraphQL. However, GraphQL lacks a lot of features and tooling.

Most of my experience is with Apollo GraphQL

• The hardest problem I faced is Authorization (not authentication). I tried graphql-shield , its still very basic.
• Existing cache solutions won't work. You need to implement it yourself or use Apollo's service. I also tried that one. But when I asked Apollo team, how to clear cache: "Oops we only have TTL, no way to clear cache". Most of the caching solutions, cdn etc are based on "URL", so its very easy to cache a route like something.com/api/users/1.

Here is an article I wrote with RestAPI, this one cannot be done if you're using GraphQL: How I used CloudFlare to reduce API response time to < 100ms

• GraphQL subscriptions/live query is in a very early stage. I found it too difficult to find whether a user is online or not, how many active clients have connected etc. And very buggy (I've filed 2-3 bug requests, some of them are still open). Again I contacted Apollo, what they said is "Pay $4000 for a month to get our support from engineers". If I've chosen SocketIO instead, it will take only a couple of mins.
• Apollo Client library - one of the biggest mistakes we've done. We thought it will be easier than redux and implemented it, now I regret! I remember Dan Abramov's talk on last JSConfig, he said "Apollo Client library is really good, interesting project, but I think it's just 5% of redux"
• File uploads are tricky - The last time I used there was no proper way to upload files using GraphQL, however now they've some specs for it and there are some libraries. Even though when I choose a component for "File uploader" in React or something, what they'll do is just post it to a URL. In GraphQL, you can't get a URL like that.

I've left GraphQL for now

I found that most of the best companies implemented GraphQL on top of RestAPIs.

I found that a better approach is built RestAPI first, do proper authentication, authorization etc, later build GraphQL on top of this RestAPIs. So you're solving all the problems as I listed above + you can use GraphQL.

Right now I've left GraphQL and implemented everything in RestAPI using Loopback in our product MFY. Needless to say, Loopback is awesome, authentication and authorization are like in heaven!

Also, removed Apollo client libraries and rewrote everything in Redux.

Pretty happy now :) In future we've planned to build GraphQL on top of Rest API's

I'm using Graphene (the python port) and stuck it behind Flask (web application server) which hides behind gunicorn (WSGI server, a python generic webapplication interface) which in turn is behind api-umbrella (an api reverse proxy). My main issue at the moment is appropriate caching when considering invalidation and retrieving different related details from different microservices. The dataloader is great but also a headache generator in that sense. But this is more backend related than graphql related.

More graphql related would be how to do proper versioning (remaining backward compatibility) and have different customers (api consumers/frontends) use the same api with slightly different requirements. You could say require different schema's, but that might not be entirely true. Still working on clarity on that.

Big pains for me was the lack of proper documentation in graphene. Also the use of Promises was new to me, and seems less natural in python than in javascript. Since I stick with python there is only graphene and no other library to choose from that compares. (unless someone can point me a library I missed)

I was about to develop an own graphql service for our product. The deal breaker was that every Java implementation of graphql I found relied on a static schema system for the data types. But the final data type set is made by our customers.

The solution would be to create a dynamic schema generator for the data scheme on runtime and check that the Java lib would allow any kind of dynamic schema loading without forking it but I haven't found the time to digg into that because it's still currently a green field project.