I'm using Strapi v4.1.7
On my local machine when I run strapi (sqlite) on dev mode and I make a api request (rest/graphql) I get the results sorted by id/createdAt from oldest ---> newest.
But when I deployed to heroku (production mode PostgreSQL) and I make the request I get the results sorted by updatedAt from oldest ---> newest.
My question is: How can I make my production version behave the same as my developement version?
in other words How can I make strapi sort entries by id/createdAt by default?
This seem to work for me in Strapi v4:
sort: "createdAt:DESC"
...
query GetVideos($page: Int!, $pageSize: Int!) {
videos(
pagination: { page: $page, pageSize: $pageSize }
sort: "createdAt:DESC"
) {
__typename
data {
__typename
id
attributes {
__typename
createdAt
publishedAt
}
}
}
}
}
`
Related
Is there a way to determine the subcsription status of an app via the Shopify node client or in the GraphQL API?
Given a user has signed up to our public app, when they log in. then I should be able to check if their Shopify subscription to our app is still active.
I can see via the GraphQL API I can query
currentAppInstallation {
activeSubscriptions {
id
name
test
}
}
This seems to return an empty array, implying my test store I doesn't have any active subscriptions. This may be due to my app and shop being in test mode though.
Does anybody know if this is the case or is there another way to get the subscription status?
Also, it would be good to do via the Shopify client if that is possible?
This is how I did if I have the APP subscription ID, I got the GraphQL query from Shopify's Billing API documentation:
query {
node(id: "gid://shopify/AppSubscription/4019585080") {
...on AppSubscription {
billingInterval
createdAt
currentPeriodEnd
id
name
status
test
lineItems {
plan {
pricingDetails {
...on AppRecurringPricing {
interval
price {
amount
currencyCode
}
}
...on AppUsagePricing {
terms
cappedAmount {
amount
currencyCode
}
balanceUsed {
amount
currencyCode
}
}
}
}
}
}
}
}
Notice that status is defined at root, so you'll get it inside the node.
I am trying to load user information from GitLab so that I can associate usernames with issues. When querying for issues, the assignee username is not directly available. Instead, a user ID is available.
If I execute this GraphQL query using the /-/graphql-explorer endpoint on my GitLab deployment:
query {
users {
nodes {
id
name
username
}
}
}
then 91 users are returned. This is clearly not all users on the deployment, though. There are users I know exist but which are not included in the result. I can query for them individually using this GraphQL query:
query {
user(username: "someusername") {
id
}
}
and receive a result which seems to correctly describe the user.
Why are some users omitted from the results for this query? I know that large result sets require dealing with pagination but the default page size is supposed to be 100 and I am receiving fewer results than this. Additionally, if I request pageinfo and ask for the users after the resulting endCursor I receive no items.
How do I submit a query that gets me all users? Failing that, how do I submit a query that will get me all users which could be assignees for a a group (or, failing that, for a list of projects)?
From the documentation :
By default, GitLab’s GraphQL API will return only the first 100 records of any collection. This can be changed by using first or last arguments. Both arguments take a value, so first: 10 will return the first 10 records, and last: 10 the last 10 records.
So you have to do the pagination yourself, your first query would be for example :
query {
users(first: 10) {
edges {
node {
id
name
username
}
}
pageInfo {
endCursor
hasNextPage
}
}
}
Then use the PageInfo result values to know if you have more pages to fetch and the cursor ID to fetch the next page, for example you could get the following result :
...
"pageInfo": {
"endCursor": "eyJpZCI6Ijc****************zNjk0MDUwMDAgOVRDIn0",
"hasNextPage": true
}
So for the next page, you have to query :
query {
users(first: 10, after: "eyJpZCI6IjcxMj**********************Ni4zNjk0MDUwMDAgOVRDIn0") {
edges {
node {
id
name
username
}
}
pageInfo {
endCursor
hasNextPage
}
}
}
And so on until hasNextPage returns false.
For more info about pagination and cursors, see GraphQL documentation : https://graphql.org/learn/pagination/
I use graghql to query data from contentful, in gatsby-node.js
exports.createPages = async ({ graphql, actions }) => {
...
const result = await graphql(
`
{
allContentfulArticle(
sort: { order: DESC, fields: date },
limit: 2000
) {
totalCount,
edges {
node {
id
title
excerpt
date
tag
content{
content
}
}
}
}
}
`
)
})
The returned id in node does not match my contentful entry's id. For example, one return id is 32015820-f327-5085-b5c0-27146850a8f5, but my entry's id is 2pljYDQAJ8umcV5po5TDK8
When I use contentful delivery api I can get the correct id, so, what happed? Who changes the id's format? How to get the correct id? The contentful plugin I use is gatsby-source-contentful.
If you open the GraphiQL explorer on http://localhost:8000/___graphql you can see the entire GraphQL schema.
As you can see there are two ID fields for each item: just id is the Gatsby ID and contentful_id is the Contentful ID. So contentful_id is what you're looking for.
I am working on a webapp with a nuxt/vuetify/apollo frontend. The backend is a strapi (v3.0.0-beta.18) server with a graphQL endpoint and a mongoDB database (v4.2.2)
It could be a newbie question since it's my first graphql project. I have a query for a collection called tags. It looks as follows:
query Tags($search: String, $selected: [ID], $limit: Int) {
tags: tags(
limit: $limit
sort: "score:desc"
where: { name_contains: $search }
) {
id
name
description
type
}
selected: tags(where: { id_in: $selected }) {
id
name
description
type
}
}
That query is returning every result that should be filtered by the where object, while the sort and limit filters work. The behavior is the same in my frontend app and on the graphQL playground. Am I missing something?
Note that strapi Shadow CRUD feature is enabled.
It turns out that I missed one of the breaking changes when upgrading strapi to the latest version. The mongose connector changed its name: https://strapi.io/documentation/3.0.0-beta.x/migration-guide/migration-guide-beta.17-to-beta.18.html
I have a GraphQL query called myAccounts which returns an array of accounts. When I go to the Playground and call the query:
{
accounts {
email
}
}
I get this result:
"data": {
"accounts": [
{
"email": "zach#email-one.com",
},
{
"email": "zach#email-two.com",
}
]
}
However, when I am in my Component, vue-apollo returns two items in the array, but seems to overwrite the second item with the first. Here is the query (in MyAccounts.gql):
query myAccounts {
accounts: myAccounts {
email
}
}
and here is the Apollo query in the component:
import MY_ACCOUNTS_QUERY from '~/apollo/queries/MyAccounts'
...
apollo: {
accounts: {
query: MY_ACCOUNTS_QUERY,
result(data) {
console.log(JSON.stringify(data))
}
}
}
and here is what vue-apollo logs out through the result:
{
"data":{
"accounts":[
{
"email":"zach#email-one.com",
"__typename":"Account"
},
{
"email":"zach#email-one.com",
"__typename":"Account"
}
]
},
"loading":false,
"networkStatus":7,
"stale":false
}
Expected behavior
I would expect the data returned in the Playground to be identical to what vue-apollo is fetching.
Versions
vue: 2.6.10
vue-apollo: #nuxtjs/apollo: 4.0.0-rc18
Additional context
I thought the result hook would be the best way to debug, but any other suggestions gladly welcomed. I assumed that this was a bug in our code, but I cannot figure out what could be causing the repetition (and mismatch).
Apollo normalizes its cache based on the __typename and the id (or _id) field. You need to include an id or _id field in your selection set alongside email. Failing to do so results in both objects being assigned the same key. If you don't have an id field to request, you'll need to provide a custom dataIdFromObject function as shown here.
From Guillaume Chau (https://github.com/Akryum):
This is because the Apollo Client cache can't compute a different ID
for the two items, so you endup with Account:undefined (or similar)
for both. Open the Apollo devtools and look at the myAccounts key in
the cache.
Learn more:
https://www.apollographql.com/docs/react/caching/cache-configuration/