GraphQL sorting multiple fields

[technology]

Describe the issue:

GraphQL playgrounds allows to select multiple fields for sorting. When i do select more than one field i get the error :

(Recommended) What’s the URL of the record or model in question?

• This is the Query as a example:

query MyQuery {
  allDatoCmsPage(locale: "de-AT", sort: {slug: DESC, id: ASC}) {
    nodes {
      position
      slug
    }
  }
}

Basically we would like to sort based on two fields. Neither the GraphQL works as shows in the picture nore using a Gatsby Customer Resolver like this does the trick

  const {entries, totalCount} = await context.nodeModel.findAll({
    type: 'DatoCmsBlogpost',
    query: {
      limit: args.limit,
      filter: {
        originalId: {ne: args.originalId},
        locales: {eq: args.locale},
        ...filter
      },
      sort: {
        fields: ['meta.publishedAt', 'title', 'id'],
        order: ['DESC', 'ASC', 'ASC']
      }
    }
  });

Could you please help out perhaps

[roger]

Hi @technology,

Any chance you can share that whole file, either here or via email at support@datocms.com?

It looks to me like an error in how Gatsby is parsing your variables, or how it’s translating them to our actual GraphQL from its intermediary layer.

If you try the same query in our CDA playground, it works:

But you see that there the query is:

query MyQuery {
  allPages(locale: de_AT, orderBy: [slug_DESC, id_ASC]) {
    position
    slug
  }
}

Maybe Gatsby is incorrectly interpolating your args…? I don’t see an arg (singular) anywhere in the query, but that’s what the error is saying. Is there an inner loop somewhere we’re not seeing?

Or else something is happening to the way it’s rewriting its internal allDatoCmsPage.nodes and sort into our actual GraphQL (which would be more like allPages and orderBy). Can you share more of the code?

Unfortunately, this sort of issue was pretty common when Gatsby was more popular… we don’t see much of it these days once we put gatsby-source-datocms into maintenance mode and started recommending gatsby-source-graphql instead. The intermediary layer was causing all sorts of issues

[technology]

Thank for the quick reply @roger

The Query i quoted above is basically just used on the Gatsby GraphQL playground. As you rightly pointed out there are not args involved.

The syntax you posted in your screenshot is apparently not supported using Gatsby Source DatoCMS, applying it so on GraphQL player does also throw an error.

Would you recommend us to Migrate to gatsby/packages/gatsby-source-graphql at master · gatsbyjs/gatsby? Even though they say that it should not be used for production?

[roger]

Hi @technology,

To be clear, Gatsby consolidates one or more external endpoints and puts it into its own data layer, using its own syntax and schema. That’s why the queries are different. In your particular case, something is wrong in that data layer’s translation process, but I cannot say what without seeing the code.

I’m not super familiar with Gatsby, but if you are able to share the repo with me, I can take a look and try to see if it’s an easy fix…? (You can share it with me on Github as r.tuan@datocms.com, or just send the files/snippets via email or PM here.)

@technology

Would you recommend us to Migrate to gatsby/packages/gatsby-source-graphql at master · gatsbyjs/gatsby? Even though they say that it should not be used for production?

Well, it’s not a straightforward answer…

If Gatsby and the old plugin are otherwise working for you, and you don’t expect many other ongoing changes, it’s probably easier for us to just troubleshoot this particular issue together to limit the “blast radius” and the amount of work needed.

If this is a project you’re just starting to build out, or in the middle of overhauling or maintaining… well… then it gets a bit more complicated

Our official stance is that we don’t really know what is happening with Gatsby, so we’re taking a wait-and-see approach. After Netlify acquired it, feature development seems to have stalled, and we are similarly pausing development work on it. That old plugin is not hard-deprecated, but it is in a maintenance mode now, and we will only provide critical updates going forward. We do know that some of our customers are still using it, so we’ll try it at least keep it minimally working as long as we’re able to, but nothing beyond that.

My personal and unofficial opinion as a peer web dev — not DatoCMS’s — is that Gatsby seems to be quite dead, and I would consider it tech debt at this point. It’s probably not worth migrating out an otherwise working and feature-frozen project, but for any work-in-progress or new project, I would personally steer away from Gatsby at this point. There are many modern and widely supported other frameworks (Astro, Next, etc.). Nobody likes the churn in the JS world, but in the particular case of Gatsby, it’s doubly bad because the data layer rewrites and abstracts what would otherwise be trivial API calls. Its intention as a federation and consolidation layer was understandably appealing at first, but the reality of it has turned out to be highly difficult to maintain through time, because every external API change essentially requires twice the work: one time to fix the data going into Gatsby, and another to fix the data coming back out of Gatsby.

Using gatsby-source-graphql (or just raw HTTP calls you make with a basic fetch) would at least help with that part of the issue, but not with the overall state of Gatsby’s seeming abandonment.

So it’s ultimately up to your team and client to see what makes sense… if this is an infrequently updated project anyway, let’s just try and fix this particular issue to make it work again. If it’s a big, ongoing part of the work you do, maybe it’s worth a cost-benefit analysis to balance keeping the existing code vs the cost of a small rewrite (to use more vanilla GraphQL) or a major rewrite (into a different framework)?