New SDK Returning Different then the old SDK

Technical Questions
1

Please fill out as many of the following questions as possible so we can help you promptly! If you don’t know how to answer or it does not apply, feel free to remove it or leave it blank.

Builder content link
e.g. Builder.io: Visual Development Platform
Builder.io: Visual Development Platform

Builder public api key
go to Builder.io: Visual Development Platform and copy your PUBLIC api key
e2f096ba17f74dfd9c140ac050f349a4

What are you trying to accomplish
e.g. I want to integrate builder on a landing page
I need the new SDK to return the same as the old SDK using the $elemMatch operator. The URL generated between the two SDKs are different but I cannot pinpoint how to adjust it to work.l

Code stack you are integrating Builder with
e.g. NextJS, react, Shopify
NextJS

Reproducible code example
If you are having integration errors, please link to codesandbox or copy and paste your problematic code here. The more detail the better!

Here is the URL generated by the old SDK that works:
https://cdn.builder.io/api/v3/query/e2f096ba17f74dfd9c140ac050f349a4/blog-article%3A4afaabe8?omit=data.blocks&apiKey=e2f096ba17f74dfd9c140ac050f349a4&sort.createdDate=-1&enrich=true&noTraverse=true&userAttributes.urlPath=%2Fblog&userAttributes.host=localhost%3A4000&userAttributes.device=desktop&options.blog-article%3A4afaabe8.limit=5&options.blog-article%3A4afaabe8.query={"data.categories"%3A{"%24elemMatch"%3A{"category.id"%3A{"%24in"%3A"[\"d491820ec5da422199336a73f388f354\"]"}}}}&options.blog-article%3A4afaabe8.model="blog-article"

Here is the URL generated by the new SDK that does not work:
https://cdn.builder.io/api/v3/content/blog-article?apiKey=e2f096ba17f74dfd9c140ac050f349a4&limit=5&noTraverse=true&includeRefs=true&omit=data.blocks&sort.createdDate=-1&enrich=true&query.data.categories.%24elemMatch.category.id.%24in="[\"d491820ec5da422199336a73f388f354\"]"

The query field is passed in differently so that is probably the cause but I just don’t know what is being expected on the API side in terms of syntax to get it to return properly.

2

Hello @kacey,

There seems to be some issue with the encoding of the query. To fix the issue with your URL, you need to make sure the query parameters are properly encoded. Here’s the corrected URL:

https://cdn.builder.io/api/v3/content/blog-article?apiKey=e2f096ba17f74dfd9c140ac050f349a4&limit=5&includeRefs=true&omit=data.blocks&enrich=true&query.data.categories.$elemMatch%3D{category.id%3D{%24in%3D['d491820ec5da422199336a73f388f354']}}

https://cdn.builder.io/api/v3/content/blog-article?
apiKey=e2f096ba17f74dfd9c140ac050f349a4&limit=5
&includeRefs=true&omit=data.blocks&enrich=true
&query.data.categories.$elemMatch={category.id={$in=['d491820ec5da422199336a73f388f354']}}

For reference, I recommend you check out our Querying Cheatsheet

3

Thanks again for taking a look at this Manish; I will have to mess around with the new SDK to try and get it to return the format you posted.

Do you have any ideas on how to do that? The old SDK accepted and worked with the syntax I used however the new SDK is not outputting the correct request that I am expecting.

4

Hello @kacey,

I recommend you check out the following Querying Cheatsheet - Builder.io

Using graphql to query model with 'foreign keys' - #2 by aziz

5

The cheatsheet only references the old SDK and that link I have followed before and it worked with the old SDK but not the new SDK

6

Hello @kacey,

I wanted to clarify that the querying cheatsheet is specifically for the content API v3 and there have been no changes to it. If you’ve been utilizing https://cdn.builder.io/api/v3/query/, which is our query API, and assuming it’s part of our old SDK, that’s not the case. The query API is still in use alongside the content API. We’ve simply upgraded our API version to v3, which I see you’re already using.

Query API is used internally within the editor and you should be using content API for fetch or querying operations.

7

The content API v3 works fine like you said but the translation to the content API v3 query params from the new React SDK makes it impossible to get the correct API call you linked. The working API call you linked includes a query parameter with no value and the = signs encoded into the key of the query param itself for the query parameter. It seems impossible to get this result when using the new React SDK without some weird work arounds.

For instance, the working API call you linked
https://cdn.builder.io/api/v3/content/blog-article?apiKey=e2f096ba17f74dfd9c140ac050f349a4&limit=5&includeRefs=true&omit=data.blocks&enrich=true&query.data.categories.$elemMatch%3D{category.id%3D{%24in%3D[‘d491820ec5da422199336a73f388f354’]}}

has these query params when parsed out:

apiKey: e2f096ba17f74dfd9c140ac050f349a4
limit: 5
includeRefs: true
omit: data.blocks
enrich: true
query.data.categories.$elemMatch={category.id={$in=['d491820ec5da422199336a73f388f354']}}:

when using the React SDK like so:

await fetchEntries({
    model: 'blog-article',
    apiKey: process.env.NX_BUILDER_IO_PUBLIC_KEY!,
    options: {
      sort: {
        createdDate: -1,
      },
      enrich: true,
    },
    query: {
      'data.categories': {
        $elemMatch: {
          'category.id': {
            $in: JSON.stringify(['d491820ec5da422199336a73f388f354']).trim(),
          },
        },
      },
    },
    limit: 5,
    omit: 'data.blocks',
  });

This should work when compared to the previous SDK but also using some of the referenced posts you pointed to but it does not. It encodes the = and your working URL does not.

I was able to finally get it to work with a hacky work around but its far from ideal.

await fetchEntries({
    model: 'blog-article',
    apiKey: process.env.NX_BUILDER_IO_PUBLIC_KEY!,
    options: new URLSearchParams(
      `query.data.categories.$elemMatch%3D%7Bcategory.id%3D%7B%24in%3D%5B%27d491820ec5da422199336a73f388f354%27%5D%7D%7D`,
    ),
    sort: {
      createdDate: -1,
    },
    enrich: true,
    limit: 5,
    omit: 'data.blocks',
  });

I essentially have to use the “scape goat” options param with an encoded URLSearchParams to get the desired result. I think this is a fairly large issue with the new SDK if I am thinking of this right as it prevents a large portion of functionality for querying data via the SDK which is the whole point.

8

Hello @kacey,

Your workaround using URLSearchParams is indeed clever, though I understand it’s not ideal. It seems like a specific requirement or limitation of how the new React SDK handles query parameters, therefore, I will try to reproduce this at the SDK level and provide you with further updates as soon as possible.

Thanks for your cooperation!

9

Thanks Manish and no worries.

I like the new SDK and the switch from using the query API to the content API was news to me as well. Your responses helped me put together my work around so I appreciate that :slight_smile:

10

@manish-sharma I realized even your provided query is not working properly. It returns incorrect results. It seems it is returning all the results without honoring the $elemMatch. I thought it was correct before because at least the first couple are valid but the last couple entries should not be returned in the response.

This is a really time consuming issue we are trying to hack together with a work around; we would really appreciate some support on this and/or some prioritization. I would not recommend the new SDK if this relatively simple function can’t be supported and I am surprised no one else has brought this up. I imagine most users are still using the old SDK and that is probably why?

11

Hello @kacey,

It appears that there may be an issue with how the $elemMatch option is being set in the request for gen2. We’re currently in the process of comparing the actual API requests for both SDK versions, gen1 and gen2.

We’ll provide you with an update as soon as we have more information. Thank you for your collaboration and patience!

12

Thank you Manish; let me know how if I can help in anyway. We poked quite a bit around trying to get it working.

Will check back in later this week if I have not heard back as its a blocking issue for some of our work

13

@manish-sharma Any updates on this?

14

Hello @kacey,

We are working on this internally, I’m happy to confirm that I was able to reproduce the issue with the elemMatch operator and have raised a ticket for our team to further investigate and offer us a workaround. I’ll try to prioritize this and update you as soon as we have made any progress.

In the meantime, we suggest exploring alternative approaches to achieve the query’s objective without relying on elemMatch .

Thanks for your cooperation!

15

This is tough to explore a work around but I will try.
We do not have a solid grasp of what query options work and in what syntax they work so its hard to even explore any options. We would need updated docs and confirmation that query operators were tested to really do this in any efficient matter.

The functionality we want is based on “related posts” in a blog. We want to query for all posts that have a shared category as a given post.

16

@manish-sharma Are there any updates to this?

We have a potential path forward but its far from ideal. We are building a separate service that basically syncs all our builder io entries and then we query that instead which defeats the purpose of the headless CMS functionality to an extent. Also building a separate service would not be an option for most :sweat_smile:

17

Hello @kacey,

We completely understand your concerns, and please rest assured that we are actively working on resolving this issue. It has already been escalated to our product team, and I’ll personally ensure to keep you updated as soon as we make any progress.

We appreciate the temporary workaround you’ve explored and your cooperation in this matter.

Best regards,