Pain points when working with GraphQL

GraphQL is cool! More and more developers are adopting to use it every day. But just as anything in the Software world, GraphQL is not the silver bullet.

I found following a very limited list of items that I consider pain points when working with GraphQL. Read through them and if you don’t find them as pain points and have a better way to solve them, please leave a comment.

When the APIs change quite rapidly

“Hold on!, APIs are not meant to change at all” you may argue. Yes, that is true, but there are cases when you start off implementation with limited knowledge of the requirement or the feature or requirement/feature may change along the way rapidly.

If this is the case, changing the schema regularly is quite painful. Things get worse if you have Backend For Frontend (BFF) implemented using GraphQL, you will be constantly changing the BFF just to get a field to Frontend.

Anyone who is going to start off with GraphQL, this is something you want to think about.

File/Media upload

GraphQL does not provide native support for file uploads. If you are working with a GraphQL server like Apollo you are in luck but working with AWS AppSync like service, one needs to devise alternative methods that do not come out of the box.

One quick but dirty way is to convert the file to Base64 encoded strings and mark the file as a String the GraphQL schema. This has drawbacks, of course, the payload file is said to increase by 30% because of this conversation.

Field names with special characters

Field names in the GraphQL schema can only contain [_a-zA-Z0–9] characters and if your field is something like “system.properties” then there is a problem.

One way to solve this is to write a function that spreads keys like the above into nested object form.

There you have it. Did you find any other pain points when working with GraphQL. Let others know in the comments.