I'm new to graphql running into issue with nested queries and need help passing an id to identify a relationship.
Queries
Above you can see the PERFORMED_FOR_Affiliation is null, though it is defined in the schema as an Affiliation type.
type Query {
affiliations(affn_id: ID!): [Affiliation]
performances(pfrm_id: ID!): [Performance]
PERFORMED_FOR_Affiliation(affn_id: ID!): Affiliation
Performance_PERFORMED_FOR(pfrm_id: ID!): [Performance]
}
PERFORMED_FOR_Affiliation query is similar to affiliations query only the relationship should return only 1 affiliation (with a matching uid).
I assume affn_id is not being passed down correctly and not sure how to do that properly. Does the PERFORMED_FOR_Affiliation need its own schema?
Schema
type Performance {
pfrm_id: ID!
mark: Int
affn_id: ID!
PERFORMED_FOR_Affiliation: Affiliation
}
type Affiliation {
affn_id: ID!
name: String
Performance_PERFORMED_FOR: [Performance]
}
I've seen some schemas that use 'nodes' and 'edge' types. As I have many other relationships would that be a better way to define the graph?
Resolvers
import performances from './mockData/performances.js';
import affiliations from './mockData/affiliations.js';
export const resolvers = {
Query: {
affiliations: (root, args) => {
return affiliations;
},
performances: (root, args) => {
return performances;
},
PERFORMED_FOR_Affiliation: (root, args) => {
return affiliations;
},
Performance_PERFORMED_FOR: (root, args) => {
return performances;
},
},
};
MockData
//affiliations.js
module.exports = [
{
"affn_id": "43700F3BE17145399924AC176EACBEF4",
"name": "Richmond Senior"
},
{
"affn_id": "8BDE709AC757416082950B1BEED0CE0A",
"name": "Cedar City"
},
{
"affn_id": "123D201BB17545E3B6ECCCCB5FC61FA3",
"name": "Delta"
}
]
and
// performances.js
module.exports = [
{
pfrm_id: "6BD41C6B1C4B43D199DE42A4A408DF1A",
mark: 1270000,
affn_id: "43700F3BE17145399924AC176EACBEF4",
},
{
pfrm_id: "EA2FBC6AB891460EA557F5B60984AD8A",
mark: 1422400,
affn_id: "8BDE709AC757416082950B1BEED0CE0A",
},
{
pfrm_id: "54A6EEB9552C49AC9F7A87E68AC272A2",
mark: 1422400,
affn_id: "123D201BB17545E3B6ECCCCB5FC61FA3",
},
]
Yes you should implement that in your resolver. I guess you will have a database in the background, e.g. mongoose:
You query for the performances and therein you populate the affiliations
performances: (root, args) => {
return new Promise((resolve, reject) => {
performanceModel.find() // find all performances
.populate("PERFORMED_FOR_Affiliation") // add values for affiliates
.exec((error, performances) => {
if (!error) {
resolve(performances); // resolve correct object
} else {
reject(error);
}
});
});
},
Related
I'm attempting to filter a query by a specific field. I can achieve this in Apollo explorer in dev tools but I can't seem to translate this into code.
The following works in Apollo explorer:
query ListUsersByType($filter: TableUsersFilterInput) {
listUsers(filter: $filter) {
items {
email
id
type
}
}
}
{
"filter": {
"type": {
"eq": "ADMIN"
}
}
}
I am unsure how this translates to the code using the useQuery hook however.
When I try the following it doesn't filter the list at all, it just fetches all of them regardless of type:
const ListUsersByType = gql`
query ListUsersByType($type: TableUsersFilterInput) {
listUsers(filter: $type) {
items {
email
id
type
}
}
}
`
const { data, loading, error } = useQuery(ListUsersByType, {
variables: {
filter: {
type: {
eq: 'ADMIN',
},
},
},
})
What am I missing here?
Your names are not correct
Here you say filter will use the variable type
const ListUsersByType = gql`
query ListUsersByType($type: TableUsersFilterInput) {
listUsers(filter: $type) {
items {
email
id
type
}
}
}
`
And here you pass filter
const { data, loading, error } = useQuery(ListUsersByType, {
variables: {
filter: {
type: {
eq: 'ADMIN',
},
},
},
})
You can
First solution
replace $type by $filter
const ListUsersByType = gql`
query ListUsersByType($filter: TableUsersFilterInput) {
listUsers(filter: $filter) {
items {
email
id
type
}
}
}
`
Second solution
rename the variable filter to type
const { data, loading, error } = useQuery(ListUsersByType, {
variables: {
type: {
type: {
eq: 'ADMIN',
},
},
},
})
My opinion
I let you choose but the first option seems the best
I am using Apollo in production for about a year and I am trying to optimize my cache management.
Let's imagine the following fictive simple schema:
type Query {
allBooks: [Book]
allCups: [Cup]
allColors: [Color]
}
type Book {
id: Int
name: String
cover_color_id: Int
CoverColor: Color
}
type Cup {
id: Int
name: String
cover_color_id: Int
CoverColor: Color
}
type Color {
id: Int
name: String
hex_code: String
}
I would like to configure cacheRedirects so that when I demand the Book.CoverColor or Cup.CoverColor (via allBooks for instance ); it will first look for the Color with matching ID in the cache, before asking the server for it.
Is that possible ?
Thanks in advance!
PS: I tried this, which doesn't seem to work:
cacheRedirects: {
Query: {
// Stuff that perfectly works
},
Book: {
// this is not even executed :(
CoverColor: (book, args, { getCacheKey }) => {
return getCacheKey({
__typename: 'Color',
id: book.cover_color_id
})
}
}
}
It depends on what your queries look like.
if your allBooks redirect returns list of ids and your query has returnPartialData enabled it should work.
if you querying allBooks without hitting redirect, there is no reason for apollo to use cached fields on each element of [Book] if it already has all data
Make a query for a single book and it should work as you expect.
type Query {
allBooks: [Book]
allCups: [Cup]
allColors: [Color]
book(id: Int): Book
}
const cacheRedirects: CacheResolverMap = {
Query: {
book: (_, args, { getCacheKey }) =>
getCacheKey({ __typename: 'Book', id: `${args.id}` }),
},
Book: {
CoverColor: (book, args, { getCacheKey }) => {
return getCacheKey({
__typename: 'Color',
id: book.cover_color_id,
})
},
},
}
Using apollo-server-express and graphql-tools, I am attempting to create a minimally viable schema from a JSON object:
const books = [
{
"title": "Harry Potter",
"author": 'J.K. Rowling',
"slug": "harry_potter",
},
{
"title": 'Jurassic Park',
"author": 'Michael Crichton',
"slug": "jurassic_park",
},
];
// The GraphQL schema in string form
const typeDefs = `
type Query {
books: [Book]
book(title: String!): Book
}
type Book { title: String!, author: String!, slug: String! }
`;
// The resolvers
const resolvers = {
Query: {
books: () => books,
book: (_, { title }) => books.filter(book => {
return new Promise((resolve, reject) => {
if(book.title == title) {
console.log('hack log resolve book _: ', JSON.stringify(book))
resolve(JSON.stringify(book));
}
})
}),
},
Book: {
title: (root, args, context, info) => {
//args is empty, need to match arg w book.title
/*
context: {
_extensionStack:
GraphQLExtensionStack {
extensions: [ [FormatErrorExtension], [CacheControlExtension] ]
}
}
, root,
*/
console.log('resolve Book args: ', args, 'info', info);//JSON.stringify(root.book))
return books.filter(book => {
if(book.title == root.title) {
return book;
}
});//JSON.stringify({"title": root.title});
}
}
};
// book: (_, { title }) => books.filter(book => book.title == title),
// Put together a schema
const schema = makeExecutableSchema({
typeDefs,
resolvers,
});
This is my repository.
When logging and stepping through node_modules/graphql/execution/execute.js, the first param of execute argsOrSchema.variableValues contains the query argument key and value, however the 5th argument variableValues is undefined.
According to some threads such as this GitHub issue I can pull the variableValues from the info argument of my resolver, however I would still like to know why the args object is empty?
Here is a gist of the info log given by GraphQL in the resolver function
The args parameter is populated by the arguments passed to the field being resolved -- any arguments passed to other fields will not be included in the args parameter.
Your schema includes a single argument (title) on the book field of your Query type. That means the resolver for that field will receive the title argument as part of its args parameter, but only if that argument is actually included in your query:
// Request
query {
book(title: "Something") {
title
}
}
// Resolvers
const resolvers = {
Query: {
book: (root, args) => {
console.log(args) // {title: 'Something'}
}
},
}
As opposed to:
// Request
query {
book {
title
}
}
// Resolvers
const resolvers = {
Query: {
book: (root, args) => {
console.log(args) // {}
}
},
}
If you pass in a value for the title argument, the only way to get that value in resolvers for other fields is to parse the info parameter. You would not look at the variableValues property, though because the value passed to an argument could be a literal value or a variable. You'd need to traverse the fieldNodes array and locate the appropriate argument value instead.
However, there's typically no need to go through all that.
If the book field is supposed to just a return a book object, your logic for selecting the right book from the books array should be included in that field's resolver:
const resolvers = {
Query: {
book: (root, args) => {
return books.find(book => book.title === args.title)
}
},
}
There is no reason to include a resolver for the title field on the Book type, unless you need that field to resolve to something other than what it will resolve to by default (the title property on the object returned by the parent field's resolver). This would be sufficient to query all books and an individual book by title:
const resolvers = {
Query: {
book: (root, args) => {
return books.find(book => book.title === args.title)
},
books: () => books,
},
}
Check out the official tutorial from Apollo for more examples and a complete explanation of how resolvers work.
If an existing service supporting the following GraphQL queries respectively:
query to a person's bank account:
query {
balance(id: "1") {
checking
saving
}
}
result
{
"data": {
"balance": {
"checking": "800",
"saving": "3000"
}
}
}
query to a person's pending order:
query {
pending_order(id: "1") {
books
tickets
}
}
result
{
"data": {
"pending_order": {
"books": "5",
"tickets": "2"
}
}
}
The source code achieving the above functionality is something like this:
module.exports = new GraphQLObjectType({
name: 'Query',
description: 'Queries individual fields by ID',
fields: () => ({
balance: {
type: BalanceType,
description: 'Get balance',
args: {
id: {
description: 'id of the person',
type: GraphQLString
}
},
resolve: (root, { id }) => getBalance(id)
},
pending_order: {
type: OrderType,
description: 'Get the pending orders',
args: {
id: {
description: 'id of the person',
type: GraphQLString
}
},
resolve: (root, { id }) => getPendingOrders(id)
}
})
});
Now, I want to make my GraphQL service schema support person level schema, i.e.,
query {
person (id: "1") {
balance
pending_order
}
}
and get the following results:
{
"data": {
"balance": {
"checking": "800",
"saving": "3000"
}
"pending_order": {
"books": "5",
"tickets": "2"
}
}
}
How can I re-structure the schema, and how can I reuse the existing query service?
EDIT (after reading Daniel Rearden's answer):
Can we optimize the GraphQL service so that we make service call based upon the query? i.e., if the incoming query is
query {
person (id: "1") {
pending_order
}
}
my actually query becomes
person: {
...
resolve: (root, { id }) => Promise.all([
getBalance(id)
]) => ({ balance})
}
You're going to have to define a separate Person type to wrap the balance and pending_order fields.
module.exports = new GraphQLObjectType({
name: 'Person',
fields: () => ({
balance: {
type: BalanceType,
resolve: ({ id }) => getBalance(id)
},
pending_order: {
type: OrderType,
resolve: ({ id }) => getPendingOrders(id)
}
})
});
And you're going to need to add a new field to your Query type:
person: {
type: PersonType,
args: {
id: {
type: GraphQLString
}
},
// We just need to return an object with the id, the resolvers for
// our Person type fields will do the result
resolve: (root, { id }) => ({ id })
}
There's not much you can do to keep things more DRY and reuse your existing code. If you're looking for a way to reduce boilerplate, I would suggest using graphql-tools.
This is the code from official docs of relay, This is for GraphQLAddTodoMutation
const GraphQLAddTodoMutation = mutationWithClientMutationId({
name: 'AddTodo',
inputFields: {
text: { type: new GraphQLNonNull(GraphQLString) },
},
outputFields: {
todoEdge: {
type: GraphQLTodoEdge,
resolve: ({localTodoId}) => {
const todo = getTodo(localTodoId);
return {
cursor: cursorForObjectInConnection(getTodos(), todo),
node: todo,
};
},
},
viewer: {
type: GraphQLUser,
resolve: () => getViewer(),
},
},
mutateAndGetPayload: ({text}) => {
const localTodoId = addTodo(text);
return {localTodoId};
},
});
I think mutateAndGetPayload executes first then outputFields? since it used localTodoId object as parameter, I see localTodoId object returned from mutateAndGetPayload.
and this is the code for relay mutation.please look at the getFatQuery
export default class AddTodoMutation extends Relay.Mutation {
static fragments = {
viewer: () => Relay.QL`
fragment on User {
id,
totalCount,
}
`,
};
getMutation() {
return Relay.QL`mutation{addTodo}`;
}
getFatQuery() {
return Relay.QL`
fragment on AddTodoPayload #relay(pattern: true) {
todoEdge,
viewer {
todos,
totalCount,
},
}
`;
}
getConfigs() {
return [{
type: 'RANGE_ADD',
parentName: 'viewer',
parentID: this.props.viewer.id,
connectionName: 'todos',
edgeName: 'todoEdge',
rangeBehaviors: ({status}) => {
if (status === 'completed') {
return 'ignore';
} else {
return 'append';
}
},
}];
}
getVariables() {
return {
text: this.props.text,
};
}
getOptimisticResponse() {
return {
// FIXME: totalCount gets updated optimistically, but this edge does not
// get added until the server responds
todoEdge: {
node: {
complete: false,
text: this.props.text,
},
},
viewer: {
id: this.props.viewer.id,
totalCount: this.props.viewer.totalCount + 1,
},
};
}
}
I think the todoEdge is from the outputFields from GraphQL? I see a viewer query on it, why does it need to query the viewer? How do I create a getFatQuery? I would really appreciate if someone help me understand this more and about Relay mutation.
mutateAndGetPayload executes then returns the payload to the outputFields
mutationWithClientMutationId
Source-Code
starWarsSchema example
mutationWithClientMutationId
inputFields: defines the input structures for mutation, where the input fields will be wraped with the input values
outputFields: defines the ouptput structure of the fields after the mutation is done which we can view and read
mutateAndGetPayload: this function is the core one to relay mutations, which performs the mutaion logic (such as database operations) and will return the payload to be exposed to output fields of the mutation.
mutateAndGetPayload maps from the input fields to the output fields using the mutation
operation. The first argument it receives is the list of the input parameters, which we can read to perform the mutation action
The object we return from mutateAndGetPayload can be accessed within the output fields
resolve() functions as the first argument.
getFatQuery() is where we represent, using a GraphQL fragment, everything
in our data model that could change as a result of this mutation