I am wondering how to deal with the following problem. I am using GraphQL to query the v4 Github API with the following query:
{
viewer {
repositories(first: 30) {
edges {
node {
name
}
}
}
}
}
This gets me a response that looks like so:
{
"data": {
"viewer": {
"repositories": {
"edges": [
{
"node": {
"name": "test-repo"
}
},
{
"node": {
"name": "another-repo"
}
}
]
}
}
}
}
I am pretty new to GraphQL, I understand that in my query I need to provide the edges and nodes but I would rather get a response back in this kind of way because I am not interested to know about "edges" and "nodes" in my frontend:
{
"data": {
"viewer": {
"repositories": [
{
"name": "test-repo"
},
{
"name": "another-repo"
}
]
}
}
}
}
I am guessing this kind of response is normal for GraphQL but it would be pretty cumbersome to rewrite to response all the time for easier usage in my frontend. Is there some way to emit the "edges" and "nodes" and get the formatting that I would like or is this simply all up to me to deal with?
I have looked at some libraries like Apollo but I have no idea is this is a right fit to deal with things like this. Hopefully someone a bit more experienced with GraphQL could tell me something more.
Sometimes, services provides two endpoints: Relay endpoint (with edges and nodes) and simple endpoint.
Looks like GitHub only have a Relay endpoint. In this case, the only thing you can do is to manually format the response on your frontend.
Actually, such complex response structure is needed because we often need to do a pagination. Take a look at the example:
{
getArticle(id: "some-id") {
id
userId
user {
id
name
}
tags(first: 10, after: "opaqueCursor") {
edges {
node {
id
name
itemsCount
}
}
pageInfo {
hasNextPage
hasPreviousPage
endCursor
startCursor
}
}
}
}
pageInfo is located at the same level as edges.
So if you later will need to do a pagination, it would be better to keep the response format as is.
You can remove the edges query if you know you aren't searching along those relationships. Cursor-based pagination will work by checking the pageInfo value hasNextPage and using endCursor as the after query parameter:
viewer {
repositories(first: 30,after:"<CURSOR_STRING>") {
totalCount
pageInfo{
hasNextPage
endCursor
}
nodes{
name
}
}
}
returns
"viewer": {
"repositories": {
"totalCount": 38,
"pageInfo": {
"hasNextPage": true,
"endCursor": "Y3Vyc29yOnYyOpHOAl/5mw=="
},
"nodes": [
{
"name": "AllStarRoom"
},
{
"name": "shimsham"
},
{
"name": "Monitor-Docs"
}
]
}
}
Related
Context:
I am trying to query for all notifications sent or received by a user in my mobile app, and am getting results that (I think) show that AWS AppSync's OR filtering is slightly broken (or that I do not understand how it works)
Note that I am performing these queries using AWS AppSync Queries, but the results are consistent when using their GUI or by sending the queries from the React Native app
Here is my list query using the OR statement
query listAllNotifsForUser {
listNotifications(filter: {sentUserID: {eq: "arbitrary-id-1"}, or: {receivedUserID: {eq: "arbitrary-id-1"}}}) {
items {
id
}
nextToken
}
}
This query returns
"data": {
"listNotifications": {
"items": [],
"nextToken": null
}
Here is my query when listing specifically notifications that have the sentUserID equal to arbitrary-id-1 (no OR statement, only the first half of the OR filter from above)
query listAllNotifsForUser {
listNotifications(filter: {sentUserID: {eq: "arbitrary-id-1"}}) {
items {
id
}
nextToken
}
}
and here is the result from that query
{
"data": {
"listNotifications": {
"items": [
{
"id": "88d204c8-7346-4f69-bc6a-c1e5db1ce5f4"
},
{
"id": "29e03351-75f0-46b2-933b-c3cca43a6067"
},
{
"id": "e21cf81a-7cb3-4331-90af-6ef266f75820"
},
{
"id": "17b42150-ae7c-4852-a58c-85d73ed2e247"
}
],
"nextToken": null
}
}
}
Notice the ONLY difference between these two queries is the removal of the 'or' and the second half of the boolean check, which from basic knowledge of programming, one would not imagine this should ever limit the results compared to a single boolean statement
Any thoughts?
I did this on my AppSync console and it worked:
query MyQuery {
listJobListings(filter: {or: [{ city: {eq: "Chongqing City"} }, { city: {eq: "Beijing"} }]}) {
nextToken
items {
city
}
}
}
Which means you'll need to do this:
query listAllNotifsForUser {
listNotifications(filter: {or: [{ sentUserID: {eq: "user-id"} }, { sentUserID: {eq: "user-id"} }]}) {
items {
id
}
nextToken
}
}
More information here
I have Strapi set up as a headless CMS and Gatsby on the frontend. In Strapi I have a "Single" type set up with a dynamic zone that the user can use to insert various components to it.
When querying directly from Strapi GraphQL, I can get the component type, like this:
{
inicio {
componentes {
__typename
}
}
}
Which returns:
{
"data": {
"inicio": {
"componentes": [
{
"__typename": "ComponentPaginasCitaBiblica"
},
{
"__typename": "ComponentPaginasAlerta"
},
{
"__typename": "ComponentPaginasTexto"
}
]
}
}
}
However in Gatsby, I get a different result:
query MyQuery {
strapiInicio {
componentes {
__typename
}
}
}
{
"data": {
"strapiInicio": {
"componentes": [
{
"__typename": "StrapiInicioComponentes"
},
{
"__typename": "StrapiInicioComponentes"
},
{
"__typename": "StrapiInicioComponentes"
}
]
}
},
"extensions": {}
}
I need to select different fields depending on the component type and be able to display them correctly on the page, however, __typename is always set to StrapiInicioComponentes. Is there another way to get this from Gatsby?
The GraphiQL explorer doesn't show anything else there:
There is an open bug about this. The fix has been merged, however, at the time of writing, it has only been added to an alpha release, so use at your own risk.
To install the latest alpha version of gatsby-source-strapi with npm, execute:
npm i gatsby-source-strapi#alpha
This adds the component type to strapi_component in the GraphQL.
Or as an alternative, you could try gatsby-source-rest-api, which exposes the component type under _xcomponent.
GraphQL lets you ask for specific fields, the response contains only the fields that you had asked for. For example:
a graphql query like:
{
hero {
name
}
}
will return:
{
"data": {
"hero": {
"name": "R2-D2"
}
}
}
where as a graphQl query like:
{
hero {
name
friends {
name
}
}
}
would return:
{
"data": {
"hero": {
"name": "R2-D2",
"friends": [
{
"name": "Luke"
},
{
"name": "Han Solo"
},
{
"name": "Leia"
}
]
}
}
}
Is there a similar mechanism/library/pattern that can be used in gRPC to achieve the same?
FieldMask is similar in protobuf. It is a list of fields to retain, so the first example would be paths: "hero.name" and the second would be paths: ["hero.name", "hero.friends.name"].
It is probably most frequently used to specify which fields should be changed in an update. But it can equally be used to specify the fields that should be returned.
The server can either process the FieldMask directly (e.g., only using the listed fields in a SELECT SQL query), or it can retrieve all the information and filter the result using FieldMaskUtil.merge() to copy just the requested fields into a new proto message to return to the client.
Currently having an issue with the relay approach to nested pagination. An example below to illustrate what I mean:
{
"data": {
"locations": {
"edges": [
{
"node": {
"id": "Location_254"
}
},
{
"node": {
"id": "Location_247"
}
},
{
"node": {
"id": "Location_217"
}
},
]
}
}
Here I have 3 locations returned from a query. Now I wanted to paginate on these locations and look at their 'history'.
query {
locations {
edges {
node {
history(
first:10
after:"eyJzbm9vemVJZCI6Mzg3fQ=="
)
}
}
}
}
This would paginate 10 results after the specified cursor. My issue is, is that this cursor is specific to the location it was obtained from. The cursor it is referring to paginate after, only applies to the location it came from.
Nested pagination tries to paginate on ALL locations here, when in actuality, the cursor being used, was grabbed from a specific location.
Am I seeing this incorrectly, or is there a better way I could be approaching this issue?
Regards, Sebastian
I'm building a GraphQL API. When returning a union / interface type field, is it possible to have the server tell me the object type? i.e. something like this
{
search(text: "an") {
... on Human {
__type
name
height
}
... on Droid {
__type
name
primaryFunction
}
... on Starship {
name
length
}
}
}
// or even better
{
search(text: "an") {
__type // <--- even though it's a Union query, everything has a type right? :/
... on Human {
name
height
}
... on Droid {
name
primaryFunction
}
... on Starship {
name
length
}
}
}
which would return
{
"data": {
"search": [
{
"__type": "Human",
"name": "Han Solo",
"height": 1.8
},
{
"__type": "Human",
"name": "Leia Organa",
"height": 1.5
},
{
"name": "TIE Advanced x1",
"length": 9.2
}
]
}
}
Obviously, I could manually add this functionality by adding "type" fields to objects as needed, but I imagine something like this is already built into GraphQL? Seeing as all of the objects already have names. Basically I'm trying to access introspection information as part of a normal query.
This is possible using the special meta field __typename, which is available on all Graphql objects and returns the object's Graphql type name. See http://graphql.org/learn/queries/#meta-fields for more info.
PS: it looks like __typename is the only meta field that can be called outside of an introspection query.
Used like:
{
search(text: "an") {
__typename
... on Human {
name
}
... on Droid {
name
}
... on Starship {
name
}
}
}