Nested query in Strapi GraphQL - graphql

I have a document structured as follows, more or less:
post {
_id
title
isPublished
}
user {
_id
username
name
[posts]
}
I know I can query fields like postConnection and userConnection with the aggregate subfield in order to query a count of all objects. But how do I get the total count of all posts by a given user?
I was able to come up with this:
{
postsConnection(where: {isPublished: true}){
groupBy{
author{
key
connection{
aggregate{
count
}
}
}
}
}
}
But this returns (expectedly) something like this:
{
"data": {
"postsConnection": {
"groupBy": {
"author": [
{
"key": "5c9136976238de2cc029b5d3",
"connection": {
"aggregate": {
"count": 5
}
}
},
{
"key": "5c99d5d5fcf70010b75c07d5",
"connection": {
"aggregate": {
"count": 3
}
}
}
]
}
}
}
}
As you can see, it returns post counts for all authors in an array. What I need is to be able to return the count for only one specific user and not by _id (which is what the key field seems to map to) but by another unique field I have in the users collection, i.e. username.
Is that possible?

Need to pass in a parameter to either the query or the field to return specific data

Related

Why does this AWS AppSync list operation using OR return an empty list even when part of the OR returns truthy values?

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

grpc/protobuffer ask for specific fields

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.

is there a way to group queries in graphQL?

I'm trying to group graphQL queries to have a more organized response.
I want to make a query for allEmployees and get back something in the following format
GraphQL Query
{
Employees:allEmployees{
id
firstName
lastName
}
}
Response
{
"data": {
"Employees": [
"new":[
{
"id": "1",
"firstName": "James",
"lastName": "Test"
},
{
"id": "3",
"firstName": "Charles",
"lastName": "Tes"
}
],
"updated":[
{
"id": "4",
"lastName": "Test"
},
],
"deleted":[
{
"id": "1",
},
],
}
}
}
I've looked into a few options to get named sub-request( like new, updated and deleted) via aliases on fragments but that doesn't seem to be a thing. I've looked at unions, but that doesn't seem to be what I'm looking for.
Ideally I would love to query graphql like...
{
Employees:{
new: allEmployees(status:"new"){
id
firstName
lastName
}
updated: allEmployees(status:"updated"){
id
firstName
lastName
}
deleted: allEmployees(status:"deleted"){
id
}
}
but I don't think it is possible to pass a nested query like this.
Is there anyway to do something like this? I'm using graphql with ruby via the graphql-ruby gem.
please let me know if anyone needs more information?
Thanks
Edit
To clarify. We have multiple entities that will follow the new, updated, deleted pattern. Looking to try and get a response where the results are nested inside a parent name/alias (Employees, Users)
{
"data": {
"Employees": [
"new":[...],
"updated":[...],
"deleted":[...],
],
"Users": [
"new":[...],
"updated":[...],
"deleted":[...],
],
...
}
That is why we would want to nest
GraphQL definitely supports nested queries and multiple top-level queries, and graphql-ruby supports these just fine.
If your GraphQL schema looks like:
type Employee {
id: ID!
firstName: String
lastName: String
}
enum Status { NEW, UPDATED, DELETED }
type Query {
allEmployees(status: Status): [Employee!]!
}
then you could write a query
fragment EmployeeData on Employee { id firstName lastName }
query Everyone {
new: allEmployees(status: NEW) { ... EmployeeData }
updated: allEmployees(status: UPDATED) { ... EmployeeData }
deleted: allEmployees(status: DELETED) { ... EmployeeData }
}
That wouldn't have quite the specific form you're looking for – there aren't good ways to add or remove arbitrary levels in your query, like adding an "Employees" label or removing layers from React-style connection records – but it can retrieve the data you're looking for.

How to return object type with union query results in GraphQL?

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
}
}
}

Spring Data ElasticSearch Build In IN query returning partial match

I am new to elastic search spring data, Today I was trying to get In query working with Spring data ES repository.
I have to do a lookup for list of user names, and if its exactly match in the index, need to get those users back as result.
I tried to use the built in repository 'In' method to do so, but it returns partial matches, please help me to make this working like SQL IN query.
Here is my repository code:
public interface UserRepository extends ElasticsearchRepository<EsUser, String>
{
public List<EsUser> findByUserAccountUserNameIn(Collection<String> terms);
}
REQUEST:
{"terms":["vijay", "arun"], "type":"NAME"}
RESPONSE:
[
{
"userId": "236000",
"fbId": "",
"userAccount": {
"userName": "arun",
"urlFriendlyName": "arun",
},
"userProfile": {
},
"userStats": {
}
},
{
"userId": "6228",
"userAccount": {
"userName": "vijay",
"urlFriendlyName": "vijay",
},
"userProfile": {
},
"userStats": {
}
},
{
"userId": "236000",
"fbId": "",
"userAccount": {
"userName": "arun singh",
"urlFriendlyName": "arun-singh",
},
"userProfile": {
},
"userStats": {
}
}
{
"userId": "236000",
"fbId": "",
"userAccount": {
"userName": "vijay mohan",
"urlFriendlyName": "vijay-mohan",
},
"userProfile": {
},
"userStats": {
}
}
]
This is because your userAccount.userName field is an analyzed string, and thus, the two tokens arun and singh have been indexed. Your query then matches the first token, which is normal.
In order to prevent this and guarantee an exact match you need to declare your field as not_analyzed, like this:
#Field(index = FieldIndex.not_analyzed)
private String userName;
Then you'll need to delete your index and the associated template in /_template, restart your application so a new template and index are created with the proper field mapping.
Then your query will work.

Resources