Does anyone have a good work around? I don’t mind the messy queries but my code has.data.attributes.become.data.attributes.a.mess.
1 Like
Not yet I fear.
I’m also realizing this breaks Apollo cache too. Does anyone have an example of they were able to get Apollo working with this new schema?
1 Like
I don’t think they will fix this soon. And there is no solutions yet.
1 Like
I just completed a (really awful) migration from v3 to v4, finally got into the graphql playground, and… yeah, that’s not good. These queries are obviously painful to read and write and my initial impression is that it’ll really screw up Apollo cache. I’m scared to see what the mutations look like.
Simplicity was one of the primary reasons I’ve sold clients on Strapi, but this migration process was painful and costly in time. That fact and the resulting decrease in usability is plenty enough reason to re-evaluate the choice, “free” or not.
You’ve had some reasonable recommendations of potential solutions here. I’d recommend you reconsider just re-explaining why you’re not going to do any of them.
Do you have any alternative for Strapi?
1 Like
There are many, but I would suggest reading the JSON:API spec, or the summary to understand what and why Strapi are doing what they are doing. It won’t necessarily make everything OK, but it will at least point your bewilderment in the same direction. When Strapi release their V4 SDK and integration tools, I think we’ll be at the point of ease we had with V3, but this hasn’t been an easy experience to migrate to v4 (at all!).
To answer your question: Ghost is the one I looked at a few years ago, it seemed like the choice at the time, but when I revisited it last year, Strapi seemed better. I think maybe because of the Beauty bias (their site is/was nicer).
1 Like
Do you use any other alternative for it?
Sorry, I don’t understand, didn’t I cover that in my response? I continue to use Strapi and I am working around the current state of things by custom mapping and generating custom types (my project is entirely in typescript).
how do you manage all the sh*** in the GraphQL response?
I gave up. I’m using REST API. I did look at GraphQL as a fix for things, but since mapping/flatten the output is a violation of GraphQL spec, I couldn’t see a way of doing it that was any better than the approach I’d half-done with my rest implementation, so I’ve gone back to that.
Thank you for your feedback. The Strapi team’s goal is to ensure that we continue to create the best possible CMS we can.
Changes, like going from Srapi v3 to v4, brought some new challenges. But we are listening to the community, even when some comments are negative.
We are also human beings, and we are working at a company where we believe in the product and want to continue making it better.
We will be holding a Livestream around Strapi v3 vs. v4 to discuss some changes made and why. Also, it would be a great place to ask questions.
You can join us here Difference Between Strapi v3 and v4, what changed, and why?
I know the migration process was difficult, specifically when migrating a v3 GraphQl Strapoi Project to v4 since we fundamentally rewrote how that is handled in version 4.
But if you have any suggestions to help us improve the process. Please feel free to let me know.
Thanks, Toby.
I know changes can be frustrating. But unfortunately, we “dropped the ball” on communicating why we made the changes.
And what is coming next to help with some of the issues we are currently facing.
Thank you all for your input.
3 Likes
We all hope to make strapi better, Even if we are some complaint users.
I don’t doubt graphql v4 has many improvements, and also has some good aspects for strapi’s future.
Besides that, here is what user want:
- if you want keep your graphql roadmap, that’s fine, but “enforce” the users to adopt new way to query is not a smart way.
- I do suggest you can have two ways to handle graphql(of course it needs a lot of work). First, enable the user use a normal graphql world query language; second, use your new query to show the task that we can’t complete when we use old graphql query way.
We should also heed the general lesson implicit in the injunction of Ben Franklin in Poor Richard’s Almanack : “If you would persuade, appeal to interest and not to reason.”
I believe tell the user your roadmap, your thinking of graphql are all “reason”, not “interest”.
The user already see the “bad” part of it, can we see the “interest” part of it ? Do we need to endure the bad part to accept the “interest” part?
In terms of engineering, keep the response as same format as restful v4 api is fine, we can easily flat the response to adopt, but the query part is hard to handle(need to clear and easy to read).
2 Likes
This was absolutely our mistake and one that we have certainly clarified that our communication was just straight up really bad before v4 launched. We should have talked more with our users (community and paid) with a two way communication flow to show the interest part of GraphQL and the new structure but also other parts of v4 like the REST population.
It’s something I personally have stressed a lot with our product, engineering, and marketing teams and that’s a big reason why @Paul_Brats is also focusing on it from the devrel side. Some information is absolutely coming to explain more on the interest side and we are making changes at the product level to be way more transparent about things before we build them such as what our expansion squad did with custom fields and their RFCs:
Both of these were to gather user feedback long before we actually started building custom fields (we just started the implementation this quarter for them). And this is what we should have done for many v4 parts including GraphQL.
I just completed a (really awful) migration from v3 to v4
[…]
this migration process was painful and costly in time.
May I ask how complex the CMS data structure was and how long it took you (roughly) to migrate?
My team of two devs is currently trying to migrate as well and at this point I’m not even sure if we can succeed at all.
If this is too off topic, maybe drop me a PM if you’d like 
From further up in the post - my code went from readable to unnecessarily complex (with no benefit).
It becomes very difficult to debug and maintain without doing something to flatten the response to the ‘old strapi 3’ format.
1 Like
Did you try to add interceptors to the response for removing unrequired and nested keys?
As a stopgap I put something on the client - which I know was bad.
I’d love it if there was a plugin to do it - or something already built. I know earlier in the thread there is a bit of code. Anything better out there?
tx
1 Like
I know this might not be as helpful to all of you that largely prefer GraphQL but a community member earlier this year did create a javascript SDK that might help you quite a bit: https://strapi-sdk-js.netlify.app/
I believe sometime in the near future we plan to adopt this and expand it quite a bit and possibly including some simplification of the response through the SDK itself. This provides solutions to both sides as we can build the features with the complexity required but the client can keep the response simple. At least that’s the idea we have been tossing around recently. (This SDK does use REST)
1 Like
Why should we use this? I mean, it is almost like using Axios with an extra layer, am I wrong?