Discussion regarding the complex response structure for REST & GraphQL (Developer Experience)

Discussions
103

I see three possible ways to solve this.

First:
Create a custom route for that use case, attach a custom controller to it, which calls the core controller, but transforms the response to your needs.

Second:
Create a custom route which uses the default controller, but attach a custom middleware to it to transform the response to your needs after the default controller has returned the response.

Third:
Use Transformer | Strapi Market which reduces the depth of the returned object. You’d still have an object in the response, but it’s not as deeply nested.

104

In the future our plan is to have our SDK do this (among other additional improvements)

105

Must it be an SDK? Isn’t it too attached to Strapi?

106

After reading this topic my team decided stop using strapi and move to our own solution. It’s impossible to keep maintaining structure, update controllers always. Strapi v4 complete fail as product version, I can’t see future in this project

1 Like
107

I invested a lot of time into strapi 3 - and dealt with the changes in strapi 4 with some client side transforms (a very poor solution I know) - but I think this will be the conclusion of most people looking at the data responses coming back from the server. Really hope it is acknowledged more and dealt with correctly. Strapi is a was a nice project but without addressing this issue I don’t see much of a future either. Unfortunately for me (and many I suspect) moving off will be painful, but necessary without changes. I wouldn’t have used strapi if I looked at Strapi 4 first as well.

108

We are now more that 1 year after that issue was open and, after a lot of “blabla”, the GraphQL schema is still the same nightmare. In addition, there is no plan to solve this in the futur (excluding v5, because no ETA nor clear commitment).

I have the following feedback:

  • a frontend SDK is NOT a solution in anyway, it just look like putting a band-aid on a wooden leg (what about CURL usage for ex. ?)
  • adding an option (disabled by default) in official GraphQL plugin, something like “use standardized Apollo schema” is NOT a breaking change so the “semver” arg is just irrelevant
  • the reason why this horrible schema was initially introduced is about adding new features in it but… one year later, where are that famous new features??

The logical conclusion is:

  • there is no real, strong reason to keep that schema
  • nothing will happens from Strapi side regarding that issue

So, if you are looking to build a new project with strapi and plan to use it’s API, just run away!
For existing project, you will have to schedule a backend migration in your roadmap.

4 Likes
109

Since this is a first found google result on “Strapi 4 simplify object”, let me share a simple GTD function which I use:

const simplifyStrapiObject = obj => {
  if (obj.data && obj.data.attributes !== undefined) {
    Object.assign(obj, obj.data.attributes);
    obj.id = obj.data.id;
    delete obj.data;
    delete obj.meta;
  }
  if (obj.attributes) {
    Object.assign(obj, obj.attributes);
    delete obj.attributes;
  }

  const relationships = Object.keys(obj).filter(key => key !== 'data');
  relationships.forEach(relationship => {
    const children = obj[relationship];
    if (Array.isArray(children?.data) && children.data?.length > 0) {
      const mapped = children.data.map(child => simplifyStrapiObject(child))
      obj[relationship] = mapped;
    } else if (children?.data !== undefined) {
      obj[relationship] = simplifyStrapiObject(children)
    }
  });
  return obj;
}

Use like for any controller, such as super.create() - here for a entity called Payment:

const payment = await super.create(ctx);
simplifyStrapiObject(payment)
return payment;

Please note that this function deliberately removes meta and therefore pagination info. Our use is for quickly returning just-created data.

1 Like
110

Just started using stapi and started loving it and then suddenly hit boom… very sad to see it, but its nightmare to go with such graphql where meta is more important then data…

any good alternatives to strapi with solid graphql support and nice UI like strapi?

1 Like
112

I didn’t find any better alternative, and I look around for two or three months.

So, I move to REST with populate parameter.

113

I wish the docs where more transparent about the issues with GraphQl, then I could have just avoided it and used the rest api.

114

I am confused, I understood this was not possible and then I see this on the Strapi Blog (Deep Dive into Strapi GraphQL):

image
image777×240 34.4 KB

I don’t manage to reproduce this very nice behavior.

115

This blog post is from Strapi v3, when the response structure was much nicer to work with.

1 Like
116

I just published very simple library which I use for my needs that can be used to flatten graphql responses from strapi v4. What I believe is neat, the typings in the library along with the flattener allow to transform nested typings to a proper flattened types.

1 Like
117

Hi, can anyone recommend an approach how we solve the Apollo cache issues?
I am not looking to add a ‘flattener’ library to our projects, nor am I interested in extensive explanations about why the current implementation is the way it is.
What I’m after are practical suggestions or strategies that I can use to resolve these Apollo cache problems.

1 Like
118

Hi, I made a script to use in the frontend that parses the GraphQL complex response into a simple one while keeping the right typescript types.

Find it here: Flatten Strapi 4's response JSON · GitHub

119

Its still a terrible structure now, but guess you have to live with it or “hack” graphql…

120

I’ve been testing out strapi for our solution but the structure does seem like a nightmare. I’m considering using the strapi backend but connecting directly to MySQL to query the database. Thoughts?

121

Any opinion on doing the data transformation on front-end instead? I’d rather flatten the Strapi API response just for a few exceptions and leave Strapi untouched. The front-end project is already using zod for runtime type checking (forms mainly).

122

Directus? The reason I gave up on Directus was due to the short comings with it’s one role per user. Now I see Strapi has some major shortcomings as well.

You could look at Hasura, it doesn’t include the Admin UI like Strapi does but it does generate a very nice API from your database.

123

Hi, can anyone recommend an approach how we solve the Apollo cache issues?
I am not looking to add a ‘flattener’ library to our projects, nor am I interested in extensive explanations about why the current implementation is the way it is.
What I’m after are practical suggestions or strategies that I can use to resolve these Apollo cache problems

I’m after the same thing. Is there any solution?