Simple GraphQL Query using the Graph - graphql

So I'm trying to learn graphql I've been playing around with the ENS subgraph on the graph
For now I'm just trying to do some simple filtering: I would like to be able to filter by the property name:
{
domains(name:"cocacola.eth") {
id
name
labelName
labelhash
}
}
However this doesn't seem to work

I don't know if I was looking at an old version of graphql when I tried making that query but when following another online I found I can specify using the where parameter:
{
domains(where:{name: "cocacola.eth"}) {
id
name
labelName
labelhash
}
}

Related

Shopify Storefront GraphQL filtering products within a collection

According to this documentation:
https://shopify.dev/custom-storefronts/products/filter-products#query-products-by-type
We should be able to filter products within a collection using collectionByHandle.
I have created a very basic test query in the Shopify GraphiQL App explorer tool. When I run the documented query, it returns all products, not filtering at all. See below:
This looks like a bug with the API right? Or am I missing something basic?
OK this turned out to be a configuration issue. To allow filtering by product type, it needs to be turned on in the admin for your store. If you navigate to:
Online Store > Navigation
... and scroll to the bottom, you will see where you can add allowed filters:
Even if it says your theme doesn't support filters, it will still change the way the API behaves.
I have the same problem, the filters param of products query seem to be ineffective and returning me all the products in the collection.
I can't find the "allowed filters" option.
Currently I'm using the Storefront API as an external app, all works fine except that.
Here the code.
query (
$collectionHandle: String, $product_filters: [ProductFilter!], $nQueryElements: Int
) {
collection(handle: $collectionHandle) {
title
products(first: $nQueryElements filters: $product_filters) {
pageInfo {
hasNextPage
hasPreviousPage
}
edges {
cursor
node {
title
vendor
availableForSale
id
handle
productType
variants(first: 40) {
edges {
node {
selectedOptions {
name
value
}
title
compareAtPriceV2 {
amount
}
image {
id
}
}
}
}
priceRange {
maxVariantPrice {
amount
}
}
images(first: 1) {
edges {
node {
id
url(transform: { maxWidth: 500, maxHeight: 700 })
}
}
}
}
}
}
}
}
const variables = { collectionHandle: this.pageURL, nQueryElements: this.nQueryElements, lastCursor: this.queryCursor.last, firstCursor: this.queryCursor.first, product__filters: [{ productVendor: "ASPESI", },], };
Thanks to who can help.
This can be done now. This post on the Shopify forum explains it perfectly with the latest API.
In case that post gets deleted, I'm going to put the info below:
We can now filter by metafields but through a collection. https://shopify.dev/custom-storefronts/products-collections/filter-products#query-products-by-metafi...
Requirements:
The metafield must have been added as a filter in the "Search &
Discovery app" or the Filters in the Navigation settings.
The metafield must be of one of these types: single_line_text_field,
boolean, numeric_integer, numeric_decimal
The Storefront API used must be 2022-04 or higher. I tested it with
2022-10
The metafield must be exposed to the Storefront API
Knowing that as of today, we have a limit of 5000 products for filters to work in a normal store (see https://help.shopify.com/en/manual/online-store/search-and-discovery/filters)
I decided to test if that restriction applies to the Storefront API, I tested it with a collection with 11769 products and I was able to get filtered results as expected. So it seems that at this stage we don't have this limitation in the Storefront API
.

Sort allContentAsset by tag in Gatsby is it possible?

I try for few days to sort my Asset media by the tag than I added on each Asset in Contentful, but I failed on each try...
See my previous question about that sort content by tag in Gatsby with Conteful API
So I'm back to a simplest configuration, just sort the raw asset !
What is good sentence to write sort and filter to catch only the media with tag artWork?
Because I try to understand the gatsby example for that... and it's not easy
https://www.gatsbyjs.com/plugins/gatsby-source-contentful/#contentful-tags
{
allContentfulAsset() {
edges {
node {
title
}
}
}
}
Sort allContentAsset by tag in Gatsby is it possible?
Absolutely. You only need to apply one of the multiple GraphQL filters in Gatsby's implementation. For example:
{
allContentfulAsset(
filter: {
metadata: { tags: { in: ["art work", "vies paralleles"] } }
}
) {
edges {
node {
title
}
}
}
}
The previous snippet will get allContentfulAsset where those tags contain "art work" and "vies paralleles". Assuming the interpolation between assets and tags exists (i.e: tags is selectable a field in assets). If this interpolation is not present or it's not properly done, allContentfulAsset will never have tags to filter so your query will break.
Keep in mind that to use tags, you need to set the enableTags flag as true (set as default as false) by:
{
resolve: `gatsby-source-contentful`,
options: {
spaceId: process.env.CONTENTFUL_SPACE_ID,
accessToken: process.env.CONTENTFUL_ACCESS_TOKEN,
enableTags: true,
},
},
According to this pull-request the enableTags feature was fixed in the cutting-edge release(5 days ago) so try to upgrade your plugin dependency.
It should be fixed in (inferred in this GitHub thread):
gatsby-source-contentful#7.5.0-next.0
Please provide feedback on previous questions/answers rather than keep opening new ones. Even delete the previous ones or provide feedback about what you've tried...

Any way to split up multiple Fragment expansions for a GraphQL query into multiple calls?

Context
This problem is likely predicated on certain choices, some of which are changeable and some of which are not. We are using the following technologies and frameworks:
Relay / React / TypeScript
ContentStack (CMS)
Problem
I'm attempting to create a highly customizable page that can be built from multiple kinds of UI components based on the data presented to it (to allow pages to be built using a CMS using prefab UI in an unpredictable order).
My first attempt at this was to create a set of fragments for the potential UI components that may be referenced in an array:
query CustomPageQuery {
title
description
customContentConnection {
edges {
node {
... HeroFragment
... TweetBlockFragment
... EmbeddedVideoFragment
"""
Further fragments are added here as we add more kinds of UI
"""
}
}
}
}
In the CMS we're using (ContentStack), the complexity of this query has grown to the point that it is rejected because it requires too many calls to the database in a single query. For that reason, I'm hoping there's a way I can split up the calls for the fragments so that they are not part of the initial query, or some similar solution that results in splitting up this query into multiple pieces.
I was hoping the #defer directive would solve this for me, but it's not supported by relay-compiler.
Any ideas?
Sadly #defer is still not a standard so it is not supported by most implementation (since you would also need the server to support it).
I am not sure if I understand the problem correctly, but you might want to look more toward using #skip or #include to only fetch the fragment you need depending on the type of the thing. But it would require the frontend to know what it wants to query beforehand.
query CustomPageQuery($hero: Boolean, $tweet: Boolean, $video: Boolean) {
title
description
customContentConnection {
edges {
node {
... HeroFragment #include(if: $hero)
... TweetBlockFragment #include(if: $tweet)
... EmbeddedVideoFragment #include(if: $video)
}
}
}
}
Generally you want to be able to discriminate the type without having to do a database query. So say:
type Hero {
id: ID
name: String
}
type Tweet {
id: ID
content: String
}
union Content = Hero | Tweet
{
Content: {
__resolveType: (parent, ctx) => {
// That should be able to resolve the type without a DB query
},
}
}
Once that is passed, each fragment is then resolved, making more database queries. If those are not properly batched with dataloaders then you have a N+1 problem. I am not sure how much control (if at all) you have on the backend but there is no silver bullet for your problem.
If you can't make optimizations on the backend then I would suggest trying to limit the connection. They seem to be using cursor based pagination, so you start with say first: 10 and once the first batch is returned, you can query the next elements by setting the after to the last cursor of the previous batch:
query CustomPageQuery($after: String) {
customContentConnection(first: 10, after: $after) {
edges {
cursor
node {
... HeroFragment
... TweetBlockFragment
... EmbeddedVideoFragment
}
}
pageInfo {
hasNextPage
}
}
}
As a last resort, you could try to first fetch all the IDs and then do subsequent queries to the CMS for each id (using aliases I guess) or type (if you can filter on the connection field). But I feel dirty just writing it so avoid it if you can.
{
one: node(id: "UUID1") {
... HeroFragment
... TweetBlockFragment
... EmbeddedVideoFragment
}
two: node(id: "UUID2") {
... HeroFragment
... TweetBlockFragment
... EmbeddedVideoFragment
}
}

Build proto3 gRPC API with overloaded endpoints

I am fairly new to API building, so this may be a broader question than I originally posed.
I am creating an API in Golang (using protobuf 3 and gRPC) that has two similar endpoints:
GET /project/genres
GET /project/{id}
The problem is that when I run curl localhost:8080/project/genres, the pattern matching results in the /project/{id} endpoint getting called with genres as the id. Is there some simple way around this, or do I have to build something into the server code to call the proper function based on the type?
I also tried flipping the ordering of these definitions, just in case the pattern matching had some order of operations that I didn't know about, but this didn't make a difference.
Here are the definitions in my proto file:
message EmptyRequest { }
message ProjectRequest {
string id = 1;
}
message GenreResponse {
int32 id = 1;
string name = 2;
}
message ProjectResponse {
int32 id = 1;
string name = 2;
}
service ProjectService {
rpc GetProject(ProjectRequest) returns (ProjectResponse) {
option (google.api.http) = {
get: "/v1/project/{id}"
};
}
rpc GetGenres(EmptyRequest) returns (GenreResponse) {
option (google.api.http) = {
get: "/v1/project/genres"
};
}
}
I was able to specify a check in the url path template to get around this issue:
rpc GetGenres(EmptyRequest) returns (GenreResponse) {
option (google.api.http) = {
get: "/v1/project/{id=genres}"
};
}
This seems to have fixed the problem. I don't know if there are other solutions, or if this is the right way to do this, but I'm happy to accept other answers if something better comes in.

GraphQL: Standard or Standish Filtering Arguments?

I'm new to GraphQL and still getting my bearing, so I apologize if this is known science or a well trod area.
Is there a standard set of arguments a GraphQL server developer should implement if they're providing field arguments for filtering? For example, as a GraphQL server developer, if I wanted to implement a greater-than or less-than API, I might do any of the following
{
author (min_date_of_birth: '...date...') {
//... fields ...
}
}
{
author (date_of_birth_greater_than: '...date...') {
//... fields ...
}
}
{
author_by_birthday (date: '...date...', operator: 'gt') {
//... fields ...
}
}
// etc...
In my research GraphQL itself appears to be neutral on this subject, but it seems slightly off that a graph query language wouldn't have a standard or standardish set of filtering arguments.
Are there standard filtering arguments that a GraphQL server developer should use? Or is this something that's left up to each server developer with no official, or even defacto, standards?

Resources