I was about to write something similar, thought of checking if someone in the community has done something similar. This was very helpful! Have been using it happily with a few edits!
Thanks for the kind words!
Iâve been using the transformer plug-in in my last few projects and it been a blast (Transformer plugin). Iâd suggest you check it out.
I personally am not using GraphQL for any new projects as it doesnât fit my needs at the moment in combination with Strapi v4.
4 Likes
The Transformer plugin is great.
2 Likes
For the vast majority of users there arenât too many reasons you need to reach for GraphQL 
Since we introduced the field selection and populate or even the nested relational filtering/sorting/ect. If anything you lose out on the ability to cache responses at the network level by using GraphQL.
(donât worry GraphQL users, itâs not going anywhere 
but we are recommending to customers to use our REST APIs over GraphQL)
2 Likes
Sounds wonderful, but wonât doing that extra step before returning the data hurt performance-wise when you get lots of request with potentially large payloads?
@DMehaffy Thank you & Strapi team for this great product. I have been migrating a client from v3 to v4 we heavily use graphql and typescript on the frontend. We are now on a bottleneck that we cannot cross because of the added complexity of data and attributes layer to the response data. I see that there is a plugin for Rest, will the be any plugin for graphql anytime soon that addresses this issue, and whats the ETA? It will be greatly appreciated if we can get some ETA to reverse the response to v3 response stricture as I am on a time crunch for my client. The ETA will enable me to communicate this issue to my client. Thanks and hope to hear from you soon.
Based on the type of transforming the data I think it could add some latency but I think it could be negligible. It basically generates a different output for the API through a middleware so I think itâs about a couple of milliseconds but Iâm not sure. It could be longer if populating more data.
1 Like
As a customer that choose strapi for its GraphQL support, itâs not very reassuring.
Itâs getting very frustrating not seen the same level of feature between REST and GraphQL.
3 Likes
Maybe you could go with Graphile and a custom inflector plugin to simplify this a whole lot (like here). But this would be limited to PostgreSQL 
No idea on how to deal with this currently. The schema that is generated by the plugin feels sadly very verbose and is missing the potential of being easy on the eyes (and hands for that matter).
I do get the point with standards, but this greatly diminishes the likelihood of anyone using the GraphQL endpoint willingly 
If anything we put REST and GraphQL in feature parity. They both basically have all the same features except REST doesnât have a decent Web-GUI for playing around in (which we are going to be working on adding).
The whole point of the structural changes was to bring both up to the same level. GraphQL was ahead in v3 (other than performance) so we elevated REST up to the same functional level as GraphQL.
Currently purposed suggestions:
- Revert to v3 style in GraphQL => Not possible at this moment
- Remove Attributes and throw everything under data in GraphQL => Not possible due to breaking changes
@DMehaffy does the telemetry show significant adoption and use of the v4 in production already? Where is this fear of breaking change coming from?
It sounds like a sunk cost fallacy to me (The Sunk Cost Fallacy - The Decision Lab)
With regards to
the structure specified is needed for some of our upcoming features (primarily content-versioning)
Which part of the structural change in the graphql response is specifically needed for this future content-versioning feature?
Is there any design draft or anything that explains what the content versioning feature is and how technically it will be implemented?
Could, perhaps, the design for content-versioning be reconsidered instead so to not impact the graphql schema in this way?
Say, if you needed to have meta for each data so you could specify some version info there, maybe just have that info available among other attributes? Just inject those fields in addition to the content-type based ones? Just poking in the dark here 
I donât currently see any good justification for splitting id and attributes for example. And split for data + meta could have been just "usual flat response + _meta field injected.
For the vast majority of users there arenât too many reasons you need to reach for GraphQL
Since we introduced the field selection and populate or even the nested relational filtering/sorting/ect. If anything you lose out on the ability to cache responses at the network level by using GraphQL.
(donât worry GraphQL users, itâs not going anywhere
but we are recommending to customers to use our REST APIs over GraphQL)
Unfortunately, this is not viable for many who, like I, have committed to GraphQL on the frontend a while back. For a ReactJS application written with Apollo Client heavily using useMutation or useQuery hooks, there is no way to switch to REST without a massive rewrite.
A bit of an off topic:
I just looked at this chart yesterday: Strapi Usage Statistics
Maybe the downward slope is a coincidence, but it could also be related to the v3 â v4 shock. And I guess initially announced quick sunset timeline for the v3 support just scared people off.
But letâs admit it, the migration is painful, at least this is my experience. Basically, everything has changed. Migrating from v3 to v4 feels like a full rewrite.
I can convince myself this is necessary evil because there are benefits I can gain on the backend.
But the need to do the massive rework of the frontend as the result of the migration is unjustified because it brings no benefits to the frontend and in fact is somewhat poisonous to it instead.
6 Likes
No, but currently we are equating the root cause towards our delay on creating/publishing the migration guides and scripts. A feedback we have already discussed at length and determined was a critical error on our part and something we will strongly be avoiding in the future.
This is something Iâm not aware of, it will be something that our product and engineer teams to determine but Iâve already talked to both teams at length to continually remind them to focus more on RFCs and gaining actual feedback before we just move into things (see delayed typescript support because we need more feedback before we will merge it into stable)
The biggest issue we have is how we release packages and our attempt this time around of actually maintaining semver. To make the changes you are proposing would be considered breaking meaning we would have to elevate the graphql package to v5.x.x. Given when I discussed this with @alexandrebodin (CTO) he was willing to do this but we need to come to terms as a company/community on the path forward. We canât make that choice yet simply because there isnât enough information about what is required from us for future features and what the community wants to see.
100% agree the migration is painful as heck, largely because we dumped a ton of technical debit and rewrote major pieces of the code-base, some stuff had been around since 2017 and before (basically v3-alpha days). This is also the first major version we have done in about near as long and there was a lot of learning that we had to do and did (some good, some bad, and a lot of this was shared to our leadership team about what not to do in the future).
I think the biggest issue we identified is a lack of communication (on both sides, but obviously largely from our side) and thatâs a problem. We (as a company) need to communicate more efficiently and effectively with all of you and likewise we need to get actionable feedback as quickly as possible from the community as a whole. One of the driving factors behind why I pushed so hard internally for us to back the new Community Org as hopefully a means to consolidate and have a dedicated entity we can converse with around feedback. Considering Strapi is only allowed one, non-voting (except as a tie-breaker when the council has an even number of seats), seat on the new community org council it keeps it so we canât exercise any means of control in the community-org.
Transparency is one of our core company values (see: Values) and we certainly failed at it here and are working to do better now.
1 Like
why nothing is mentioned about this in the migration guide? 
2 Likes
Fantastic question, of which I donât have the answer to but I will pass the question along.
THANK YOU! I saved like 20+ hours because of this <3
1 Like
Is this the official view on GraphQL? Makes me wanna run away⌠
1 Like
We are planning on writing a blog post and doing some AMA live streams I think to give into this a bit more and explain why some of it is required for the future with the features we will be building.
1 Like
If that is the case, then it will be hard to recommend using Strapi. Having a solid graphql API was one of the main points for me choosing Strapi for my clients.
5 Likes
I started using Strapi because itâs fast easy to use setup and its support of GraphQL. Itâs really discouraging to learn the team sees GraphQL as something many people donât need.
6 Likes