Make hosted version of Uniquery

[vikiival]

Context

We have been asked to implement this as few apps use native lang (Swift, Kotlin) or they are over the capacity to implement raw GraphQL.

Task

Create an REST API server (use either nitro or hono)

Implement routes defined in https://github.com/kodadot/uniquery/issues/10#issuecomment-1456270265

⚠️ the current limitation of our uniquery api is to filter just only by one field. So I would check what is the first key and take it as important.

Make sure also limit and offset are available

Ref

please use good api practices as mentioned by @roiLeo in

• https://github.com/kodadot/uniquery/issues/10#issuecomment-1456270265

Routes to include in next // basically all uncommented.

[vikiival]

I will go with @honojs

[roiLeo]

• https://github.com/stacksjs/stacks 👀

[vikiival]

[vikiival]

cc @kodadot/internal-dev

[preschian]

i can pick this one 👋🏻

[roiLeo]

link kodadot/ops-internal#1337

Context

We have been asked to implement this as few apps use native lang (Swift, Kotlin) or they are over the capacity to implement raw GraphQL.

Why do they need rest-api endpoint when they can do gql query directly to our endpoint? another gql wrapper? I've check some part of Talisman they already use some gql, for Nova they use https://squid.subsquid.io/dot-ordinals/graphql

[yangwao]

I'm thinking loud, wouldn't be easier setup this for them?

• https://stellate.co/docs/graphql-developer-portal

Why

It would save us time for thos few integration and we can invest time elsewhere as API is not our core product now

[preschian]

eehh, sorry. I'm a bit lost. Should I continue or hold it for now?

[vikiival]

I'm a bit lost.

1. Research if https://stellate.co/docs/graphql-developer-portal would help us with integration
2. Output research
3. We will agree on next steps

[preschian]

I enabled the developer portal here: https://query-stick.stellate.io/

Since it is still in Beta, we can only edit a few sections. So far, we can only edit under the Readme section.

[yangwao]

query-stick.stellate.io

https://query-stick.stellate.io/#api-keys api-keys should go somewhere?

[preschian]

query-stick.stellate.io/#api-keys api-keys should go somewhere?

Afaik no need for api-keys to consume our stellate query. I already turned off the authentication, but not sure this section still shows up

option on dashboard:

results:

[yangwao]

ah yes, now I see it, okay seems works. Yes API keys are kinda crucial to see who doing what amount of queries

also, looks like it's good only as private token not as public they say but I think still okayish to use in their requests

[yangwao]

@preschian any output from research if it would be good as REST API?

I think I can sign up for a Stellate account, and we will need a paid seat I guess?

[preschian]

@preschian any output from research if it would be good as REST API?

"Developer Portal" only helps us to create a documentation portal for our GraphQL endpoint. At the moment, so many features still need to be fixed.

Since it is only for creating a documentation page, for now, it's better to put the documentation on our developer portal instead: https://developers.kodadot.xyz/core-concepts/kodadot-stack/indexer/kodadot-indexers.html.

They can fetch POST requests to our graphql endpoint if we want to avoid creating another wrapper. I put a code example in this section: https://query-stick.stellate.io/#graphql-endpoints

Maybe let's try to create documentation on how to fetch POST requests to our GraphQL endpoint. Then, gather feedback from them.

Code example:

let headersList = {
  "Content-Type": "application/json",
};

let gqlBody = {
  query: `query MyQuery {
  nftEntities(
    limit: 10
    where: {currentOwner_eq: "DY4SQF2iD456tH89aQtz5wv1EV3BbSW8wKKuMcwbmXaj1pM"}
  ) {
    id
    name
    meta {
      id
      image
      animationUrl
    }
  }
}`,
  variables: "{}",
};

let bodyContent = JSON.stringify(gqlBody);

let response = await fetch("https://query-stick.stellate.io/", {
  method: "POST",
  body: bodyContent,
  headers: headersList,
});

let data = await response.text();
console.log(data);

[preschian]

I think I can sign up for a Stellate account, and we will need a paid seat I guess?

better to use paid seat, I think. and wrap our another subsquid endpoint with that. plus, our internal dev member can access to the stellate dashboard

[yangwao]

better to use paid seat

okay can proceed, putting in pipeline

[yangwao]

okay can proceed, putting in pipeline

cc @preschian

[preschian]

okay can proceed, putting in pipeline

cc @preschian

preparing 👍🏻

[preschian]

Because @yangwao set up a new subdomain with api.kodadot.xyz, I think we can use this as a reason that we need REST API also. Since we don't have a multi-chain indexer yet, we can use REST API for multi-chain data.

I like the subdomain name tho. The naming is something like this:

api.kodadot.xyz -> REST API -> can wrap our queries from ahp and ahk

api.kodadot.xyz -> ahp -> gql-ahp.kodadot.xyz
                -> ahk -> gql-ahk.kodadot.xyz
                -> other chain here...

Example request:
- api.kodadot.xyz/ahp/nft/id
- api.kodadot.xyz/ahk/collection/id

Once we support multi-chain indexer, we can use our subdomain also:

gql.kodadot.xyz -> our multi-chain indexer

while waiting our multi-chain indexer, this is the naming for our specific chain indexer

gql-ahp.kodadot.xyz -> our specific chain indexer
gql-ahk.kodadot.xyz -> our specific chain indexer

So, our goal is, we should have two subdomain:

• api.kodadot.xyz
• gql.kodadot.xyz

[yangwao]

Meanwhile

• https://github.com/kodadot/nft-gallery/issues/9469

[yangwao]

The naming is something like this:

@preschian let's proceed in private workers for start?

[preschian]

@preschian let's proceed in private workers for start?

on it 🙏🏻. should be finished by tomorrow morning

for private-workers