By default the Amplify GraphQL APIs return deleted items.
Worse, as near as I can tell there is apparently no way to filter them: Neither syncXYZTable nor listXYZTable queries accept the _deleted field as a parameter. Fortunately the generated code in the DataStore SDK filters out these items, and (somewhat confusingly) the Amplify Studio does not display them (in the Contents tab); but this only highlights the inconsistency: For example as a developer I don't see deleted items anywhere, but as a data scientist or manager using the GraphQL API, I have (it seems) no way of avoiding them.
Am I missing something. Is there really no way to filter out deleted items using the Amplify GraphQL API?
I had to filter these _deleted records in the code. Did not find a way to filter out in GraphQL Response
Related
I would like to be able to use custom headers in queries and mutations.
Basically it would be some context that all the queries and mutations should take into account.
I cannot find a way to do it. Is it even possible with the the current (v2.15.0 as of writing) version of Hasura?
Tried searching the web
How do you obtain the click share data on Google Ads API?
https://developers.google.com/google-ads/api/fields/v8/ad_group?hl=en
When you see this Google Ads API, it states that 'There's metrics that you can't use ad_group with FROM. ' The click share falls under this and we don't know how to obtain the data. Anyone have any idea how?
You could try their query in this query builder provided by Google.
From my experience, you can't query some field together. My guess is some fields are like group by in SQL so there is no way you can query both at once. Using the query builder, you could find out which field are exclusive to each other.
So I have a very basic content model in Contentful. On the category field, I have validation rules that only let the user choose from the predefine options.
I'm trying to query what these options are in graphQL. IE, a query that returns 'Day Ticket' and 'Season Ticket' + any additional ones that are added in the future of course. No luck so far, any thoughts?
content model
validation inputs
Contentful DevRel here. đź‘‹
I don't think that's possible via the GraphQL API. The GQL api works on with publish and preview data. The available functionality is more or less mapping to the data available in the Content Delivery API and Content Preview API.
To retrieve this information you'd have to communicate with the Content Management API (CMA). You'll find the information when you fetch a content model.
âť—Heads up, don't put a CMA token in the client (the browser). The CMA is a read/write API. If you leak the token to authorise people could alter your Contentful space and the data it includes.
In the slack UI, when I make a search, it makes a request to the search.modules endpoint. There's also the option to exclude apps and bots from the result, which translates to a boolean POST param to that api endpoint.
https://api.slack.com/methods doesn't list such a method, and only has search.messages, search.files, and search.all.
How can I use the API to search, but exclude bot accounts? Do I need to leverage this seemingly hidden search.modules (which probably is inaccessible with a bot acct)? Is there a better way than making a list of bots and manually filtering them out of search results?
Well it's not in the documentation anywhere, but I can achieve this with the search.messages api by adding search_exclude_bots=True to my POST data.
Since this is undocumented, I'm curious as to whether users should be using this param and if it will be changed in a breaking way in the future.
Is it a good practice to have a viewer for GraphQL mutations? Theoretically this makes sense to me as some mutation end points shouldn't be possible if you are not logged in, etc.
But when I see examples on the web, I only see implementation of GraphQL viewers for queries. For mutations, I do not see any implementation of viewers. For example, the GitHub API doesn't have a viewer on top of all their mutations.
The viewer field isn't a good practice, either for mutations or queries. It's a remnant of Facebook's legacy GraphQL platform from before it was open-sourced, which didn't allow arguments on root query fields. This meant that all of the fields needed to be moved one level down, below viewer.
The current way to do auth in GraphQL, at least in the JavaScript implementation, is by getting the user data based on something like an HTTP header and putting it on context, as mentioned here: http://graphql.org/learn/authorization/
Therefore, there is no reason to do viewer for mutations, or for queries. Most GraphQL clients don't mind, but one situation where it could make sense to have it in queries specifically is if you are using Relay 0.x, which has inherited some of Facebook's legacy GraphQL limitations. Hopefully a future version of Relay will remove this requirement.
For an additional source, read this comment from Lee Byron, one of the original creators of GraphQL.