This post is a branch of "Sharing data in a Microservices Architecture using GraphQL" where I explore some problems integrating services in a Microservices Architecture and how GraphQL comes in handy to solve some of them.
For some time working and studying GraphQL, I have found some important concerns for anyone considering using this tool. In this post I’ll summarize these concerns and list some actions that can be taken as workarounds.
We will cover three main types of concerns/problems:
1 — Almost impossible to solve:
- Query In Indefinite Depth
TL;DR: GraphQL cannot query in indefinite depth, so if you have a tree and want to return a branch without knowing the depth, you’ll have to do some pagination.
- Specific Response Structure
TL;DR: In GraphQL the response matches the shape of the query, so if you need to respond in a very specific structure, you'll have to add a transformation layer to reshape the response.
2 — Hard to solve:
- Cache at Network Level
TL;DR: Because of the commonly way GraphQL is used over HTTP (A POST in a single endpoint), cache at network level becomes hard. A way to solve it is to use Persisted Queries.
- Handling File Upload
TL;DR: There is nothing about file upload in the GraphQL specification and mutations doesn’t accept files in the arguments. To solve it you can upload files using other kind of APIs (like REST) and pass the URL of the uploaded file to the GraphQL mutation, or inject the file in the execution context, so you’ll have the file inside the resolver functions.
- Unpredictable Execution
TL;DR: The nature of GraphQL is that you can query combining whatever fields you want but, this flexibility is not for free. There are some concerns that are good to know like Performance and N+1 Queries.
3 — When not to use GraphQL:
- Super Simple APIs
TL;DR: In case you have a service that exposes a really simple API, GraphQL will only add an extra complexity, so a simple REST API can be better.