Yes there is an abstraction layer for sure, the end goal being better developer experience on the client side (one the principles that GraphQL was built on too, though it’s debatable on that principle as well considering how subjective that opinion is).
At the end of the day what makes good UX largely boils down to abstraction. You apply a human readable abstraction onto a complex set of code that isn’t human readable. The SDK is as it’s name implies, it’s a kit or set of tools that simply the development of software (AKA a software development kit).
Ideally the purpose of this SDK is to make requesting data and transforming the response easier so you can think less about it on the client side and let the SDK do the heavy lifting.
If you would rather do that manually yourself, then certainly that’s not a problem. Only trying to offer potential solutions for now.
Going with GraphQL instead of REST is not only about the transport layer or how the requests and responses are sent.
It also imposes design constraints on the backend, i.e. how one writes the controllers and services.
When you go with GraphQL, you think in terms of resolvers.
When composing a complex response object, each field that it can return can be resolved by a separate resolver that GraphQL plugin will call when the field needs to be populated. This is where the flexibility of GraphQL comes from.
So, the transition from GraphQL to REST based SDK won’t happen for those who already deep in this sh*t (excuse my French here :))
Also, the client side tooling, if you use GraphQL, chances are you are using Apollo client or similar with all their caching and hooks with reactive updates to queries, etc…
Unless SDK can be just plugged in to Apollo link chain just like a transport layer transformer, this SDK won’t see much traction with the part of the community that has been affected by this GraphQL rewrite the most.
These are my 2 cents (and all above is my opinion only).
With the excessive nested data and bloated responses you made the developer experience horrible.
I don’t think any feature or plugin you might add in the future will make up for this.
You most likely forgot the reason why people started using strapi in the first place.
Reading this thread made me really sad.
I see that I need to rewrite and test all of my code in order to make my system work on v4. My system uses both REST and graphql interfaces and from the thread, I see that the structure of the response has changed for both of them.
I understand that you need to change stuff when developing Srapi and I need to change my code to benefit from the new functionality in new versions.
But I do not see any benefits from upgrading to v4. I just see a lot of rewriting and testing that I have to do just to get my code working on v4. I would rather spend time developing my system, than making the system work with v4.
My system sync/read data from 7 external APIs in order to populate a catalog of 100.000 companies. I’m not sure how much time I need to spend rewriting my system. But I know it will not be a joyful task. And when I finish it will be the same as today, with no new functionality.
I have enjoyed using Strapi for the past two years and recommended it to others. But now I have to evaluate if I want to rewrite my code for v4 or find an alternate to Strapi.
I have a lot of rewriting to do either way. So, Strapi, can you please tell me why I should decide to rewrite for v4?
Tried to start a new project yesterday. First time with v4. Then I saw the super strange json structure the REST Api was giving me. I’m consuming the API with native iOS and Android apps.
Especially in iOS with v3 I could ditch DTO objects and could map JSON responses directly to my model structures. I loved this simplicity.
Now I need a workaround, since I’m not willing to adopt this new structure in my apps. Especially with deeper nested objects, it’s a nightmare.
@DMehaffy + team. I understand your decisions. Sure, there is a standard you adopt with this structure. It’s good for upcoming features, okay. But at least give us a big switch, like for enabling the publish system. Because those new features are not here yet and even if they’re there, only a subset of users will need it.
Maybe an option would be to extract the transform code of roel in to an officially maintained and tested plugin?
We aren’t again making changes but for most of that to happen it will need to wait for v5. We have, for now, committed to this decision for the v4 scope but that is of course subject to change with v5.
Once we get closer to working on v5 we will be opening lines of communication to detail some plans and get feedback wayyyyyyyy in advance unlike the v3 to v4 process.
For now we can’t really spare the engineers to work on a plugin/modification like this but we are happy to assist any community member picking up such a complex topic. We do plan to work on an official javascript SDK in the next 6 months that hopefully will handle most users use-cases (think like the transformer but on the client side instead).
I don’t have exact ETAs on v5 nor the SDK only that I know they are on our internal roadmap.
The structure also made me crazy. and I try to use some flatten plugin, It doesn’t work on graphql. So I try to modify the official graphql plugin in my local repo. If someone think it is a temporary solution to choose. you can check my progress in github Modify Official GraphQL plugin to flatten response! Temporary!!!
and next imgs show my progress now.
after plugin modified:
I found transformer plugin doesn’t support graphql yet, and I don’t want to transform response, I want to try to modify the typeDefinition of the plugin for temporary using.
And I found that I didn’t modify mutations now, I am not sure it works or not
Yes, That’s a good idea to update that plugin, the author have done a great work for helping someone else. Because I just use graphql in development now, I think the modifying temporary way is enough for me now. I also hope the idea can help someone else.
I found every reply post make the question more clearly, and some temp solution found. Hope strapi v5 will be better.
Hi, it’s been a long time. Does any one have any idea why this code does ABSOLUTLEY NOTHING in React Native? But works perfectly good in React js?
Thanks!
Hmm, maybe it has something to do with Object.prototype.toString.call. I’m no React Native expert, but I can think this isn’t supported natively (pun intended) on React Native.
However, apart from my snippet, i’d suggest you’d use the Transformer | Strapi Market plugin, but that does only work for REST however.
I am following this discussion, read all post up to here.
And I started to get worried about my plan to use Strapi for my project.
I started to explore Strapi with v3 and went to v4 meanwhile and my first experiments did not make me realize yet what these additional structures data/attributes will mean to me in the longer term.
Now I am working on connecting my Vue Storefront frontend with Strapi and I had to learn how GraphQL works and ran into a few unclarities and while resolving them I found this thread.
And I am becoming unhappy with that new format, too.
Thinking about it I realize that there are actually different use cases for Strapi that users (developers) might have and the Strapi team focussees on one direction of use cases that will not be relevant for all developers.
At this time I am one of these who do not care about the feature set behind the new structure. I want simplicity behind the integration I am doing.
So I introduced that branch of the graphql plugin mentioned above that would simplify the format.
I would propose to Strapi to give the users / developers options and enable the simple path as well.
I think that will be fundamental for the product, unless the path that the Strapi team sees is clearly the essential and only one and it is worth to exclude the other use group - that’s whats going to happen that developers looking for simplicity will shy away in the long term.
Hello guys, just came across this thread. Wondering if there is a way to target specific fields data without having it nested in data and attributes i.e. if I want the access the value of a specific field below in the example called snipcartCrawl which in this case is a JSON field, I’d like to be able to access the JSON value of snipcartCrawl (which is currently null) and just have that returned as the API response so my response is just whatever the JSON value is of that field. Is this possible? Managed to wittle it down using ?fields[0]=snipcartCrawl. I only ask because my specific use-case here needs the JSON from the URL rather than retrieving it first and then doing loops etc to access the data within.
