opened 09:29AM - 22 Nov 21 UTC
closed 01:21PM - 24 Nov 21 UTC
type: feature request
source: plugin:graphql
Squad: Developer Experience
<!--
Hello 👋 Thank you for submitting a feature request.
We are using Produc…tBoard to manage our roadmap and feature requests.
Can you please submit your feature request here: https://portal.productboard.com/strapi
-->
## Feature request
### Prelude
The below is an opinion. It is based on my experience, may not be complete and I may have missed something, that said I would love for this opinion to be considered, and to hear other people share their thoughts/suggestions.
### Summary
After a few of weeks of working with V4 and GraphQL, I've made a decision to scratch those weeks of work and move away from V4 for ' time being.
Below are the biggest pain points that made me do it.
### Why is it needed?
After trying to switch to V4 using GraphQL, sadly I've discovered that DX could be muuch better.
GraphQL is not going anywhere and Strapi providing a solid and good DX for GraphQL would surely pave way for a whole ecosystem of new potential users and honour the existing GQL lovers.
### Current pain points(s)
1. Defining routes is a pain, especially if compared to what it was like in **V3**
2. Managing User Permissions is much harder and convoluted (somewhat related to the first pain point)
3. While extending `Mutation` the way it currently is needed to is not per se Strapi related problem, it would be amazing if Strapi would handle this by simply creating a new resolver (I believe this is somewhat how it worked in **V3**)
4. The response format is not great for those working with say Apollo Client 3 (or other clients with cache normalization), where the _GQL Client_ relies on a unique identifier inside it _GQL type_ to track the given object. So having the `ID` inside the `attributes` would be beneficial. Furthermore the nested `data {}` inside the response it somewhat verbose and not sure if it's great DX, not only for the sake of the proportionally increasing nullity checks with each nested relation, but also since it - _again_ - increases the complexity for using the _GQL Client_ with **cache normalization** (this could be solved with something like [`custom merge functions`](https://www.apollographql.com/docs/react/caching/cache-field-behavior/#the-merge-function), but that surely would not be a good DX. **_Perhaps_** this could be solved by moving the `metadata` inside the actual response, say instead of
```graphql
query {
posts {
data {
id
attributes {
title
...
}
}
meta {
pagination {
...
}
}
}
}
```
it could be this:
```graphql
query {
posts {
id
title
meta {
pagination
...
}
}
}
```
The approach as in V3 where it was possible to map the same controllers to GraphQL and REST was great, perhaps there is a way to provide same DX with the new engine improvements.
### More context
Please don't hate me Strapi folks, you know I love you. But I feel like we're at the point where it's either speak now or forever hold your peace, so. 😄
IMHO, regardless of the fact that (as far as I know) the percentage of current Strapi users for GraphQL is low, it is still a very important piece of the puzzle for a modern headless CMS tool. Furthermore, I believe the number has been historically so low because the DX was not great - now unfortunately it seems it has potentially gotten further from great.