I am trying to separate all the tables in different directory. However, I am encountering some problems. Look at the ExpenseItem below. ExpenseType is under ExpenseType directory so graphql throws error. In order to solve that I need to add ExpenseType in ExpeseItem/typeDefs which is redundant.
ExpenseItem/typeDefs
type ExpenseItem {
id: ID!
name: String,
updatedAt: DateTime,
expenseType: [ExpenseType]
}
Is there any better way to stitch the schema?
I also tried something like this. However, graphql stop working.
When I query, it does not goes into the resolver, is there anything wrong on setup?
const schemas = makeExecutableSchema({
typeDefs: `
scalar JSON
scalar DateTime
type Query {
test: String
}
${typeDefs1}
${typeDefs2}
${typeDefs3}
${typeDefs4}
`,
resolvers: {
// Type resolvers
JSON: GraphQLJSON,
DateTime: GraphQLDateTime,
// schema resolvers
...resolvers1,
...resolvers2,
...resolvers3,
...resolvers4
}
})
const server = new ApolloServer({
schema,
context: { db }
})
You cannot merge your resolvers like this. Using the spread operator to merge an object results in a shallow merge. If the merged objects share any common properties (for example, Query), only the last merged property will be present in the resulting object. You need to deep merge the objects. You can do so yourself, or use something like lodash's merge.
Additionally, you can pass an array of strings as the typeDefs to makeExecutableSchema instead of combining them yourself.
Related
I have a mutation:
const createSomethingMutation = gql`
mutation($data: SomethingCreateInput!) {
createSomething(data: $data) {
something {
id
name
}
}
}
`;
How do I create many Somethings in one request? Do I need to create a new Mutation on my GraphQL server like this:
mutation {
addManySomethings(data: [SomethingCreateInput]): [Something]
}
Or is there a way to use the one existing createSomethingMutation from Apollo Client multiple times with different arguments in one request?
You can in fact do this using aliases, and separate variables for each alias:
const createSomethingMutation = gql`
mutation($dataA: SomethingCreateInput!) {
createA: createSomething(data: $dataA) {
something {
id
name
}
}
createB: createSomething(data: $dataB) {
something {
id
name
}
}
}
`;
You can see more examples of aliases in the spec.
Then you just need to provide a variables object with two properties -- dataA and dataB. Things can get pretty messy if you need the number of mutations to be dynamic, though. Generally, in cases like this it's probably easier (and more efficient) to just expose a single mutation to handle creating/updating one or more instances of a model.
If you're trying to reduce the number of network requests from the client to server, you could also look into query batching.
It's not possible so easily.
Because the mutation has one consistent name and graphql will not allow to have the same operation multiple times in one query. So for this to work Apollo would have to map the mutations into aliases and then even map the variables data into some unknown iterable form, which i highly doubt it does.
I'm a newbie to Prisma/GraphQL. I'm writing a simple ToDo app and using Apollo Server 2 and Prisma GraphQL for the backend. I want to convert my createdAt field from the data model to something more usable on the front-end, like a UTC date string. My thought was to convert the stored value, which is a DateTime.
My datamodel.prisma has the following for the ToDo type
type ToDo {
id: ID! #id
added: DateTime! #createdAt
body: String!
title: String
user: User!
completed: Boolean! #default(value: false)
}
The added field is a DataTime. But in my schema.js I am listing that field as a String
type ToDo {
id: ID!
title: String,
added: String!
body: String!
user: User!
completed: Boolean!
}
and I convert it in my resolver
ToDo: {
added: async (parent, args) => {
const d = new Date(parent.added)
return d.toUTCString()
}
Is this OK to do? That is, have different types for the same field in the datamodel and the schema? It seems to work OK, but I didn't know if I was opening myself up to trouble down the road, following this technique in other circumstances.
If so, the one thing I was curious about is why accessing parent.added in the ToDo.added resolver doesn't start some kind of 'infinite loop' -- that is, that when you access the parent.added field it doesn't look to the resolver to resolve that field, which accesses the parent.added field, and so on. (I guess it's just clever enough not to do that?)
I've only got limited experience with Prisma, but I understand you can view it as an extra back-end GraphQL layer interfacing between your own GraphQL server and your data (i.e. the database).
Your first model (datamodel.prisma) uses enhanced Prisma syntax and directives to accurately describe your data, and is used by the Prisma layer, while the second model uses standard GraphQL syntax to implement the same object as a valid, standard GraphQL type, and is used by your own back-end.
In effect, if you looked into it, you'd see the DateTime type used by Prisma is actually a String, but is likely used by Prisma to validate date & time formats, etc., so there is no fundamental discrepancy between both models. But even if there was a discrepancy, that would be up to you as you could use resolvers to override the data you get from Prisma before returning it from your own back-end.
In short, what I'm trying to say here is that you're dealing with 2 different GraphQL layers: Prisma and your own. And while Prisma's role is to accurately represent your data as it exists in the database and to provide you with a wide collection of CRUD methods to work with that data, your own layer can (and should) be tailored to your specific needs.
As for your resolver question, parent in this context will hold the object returned by the parent resolver. Imagine you have a getTodo query at the root Query level returning a single item of type ToDo. Let's assume you resolve this to Prisma's default action to retrieve a single ToDo. According to your datamodel.prisma file, this query will resolve into an object that has an added property (which will exist in your DB as the createdAt field, as specified by the #createdAt Prisma directive). So parent.added will hold that value.
What your added resolver does is transform that original piece of data by turning it into an actual Date object and then formatting it into a UTC string, which conforms to your schema.js file where the added field is of type String!.
I've the following structure in my schema:
type gn_Feature implements Some_Interface {
s_description: String
s_id: URL!
some_parent: gn_Feature
}
As you can see, each gn_Feature has an another linked gn_Feature object (the linking is handled elsewhere, it doesn't really matter). By my current understanding, you only need to define the resolvers for the return types, so my resolvers look like the following:
export const resolvers = Object.assign(
{},
{
DateTime: DateTime,
Date: DateTime,
Time: RegularExpression("Time", /^\d{2}:\d{2}(:\d{2})?$/),
URL,
Query: {
gn_Feature: gn_FeatureResolver
},
gn_Feature: gn_FeatureResolver
}
);
But, my queries fail with the following error if I don't explicitly define the resolver for the nested field, like so:
gn_Feature: {some_parent: gn_FeatureResolver}
Error:
"message": "Resolve function for \"gn_Feature.s_description\"
returned undefined"
My resolver function doesn't even get invoked for my nested object when I don't specify it like the above.
My backend consists of some voodoo transpiling of GraphQL queries into SparQL queries which return data back so I won't post the resolver code as I utilize one universal resolver for many fields. I'd like to avoid having to specify resolvers for each nested field as that's going be extremely tedious (I have dozens of types with dozens of fields). Any clarifications are welcome, as I'm completely baffled.
Example GraphQL query:
gn_Feature(some_field:"AD", last:2){
s_description,
s_id
some_parent{
s_description
}
}
When executing a query, only the value of any particular field is initially unknown and needs to be resolved... everything else, like the types, selection sets, etc. is already known. A resolver is a function called to resolve a specific field. In GraphQL.js, there are no resolvers for types.
Apollo muddies the waters a bit in this regard, since for convenience, the API for makeExecutableSchema allows you to define custom scalars by including them in the resolver map. Additionally, even though interfaces and unions don't have resolvers either, Apollo lets you use the resolver map to specify a __resolveType function for these abstract types as well. Apollo's docs actually define a resolver as "a function that connects schema fields and types to various backends." However, in the context of GraphQL in general, you should think of a resolvers as "a functions that resolves the value of a field".
So, given a type called gn_Feature and a field called some_parent, this is the correct way to structure your resolvers:
const resolvers = {
gn_Feature: {
some_parent: someResolverFunction
}
}
Also note that Query and Mutation are both types themselves, so if you have a query called gn_Feature, you are actually resolving a field called gn_Feature for the Query type.
Note: This is a followup question to my previous question about Apollo GraphQl Storing derived data
I'm using apollo-link-state to store data that's derived from query data. In this example the query data from the db includes some (x,y) points on a graph and the derived data is slope, moving average, acceleration etc.
My React graphing components need different combinations of original and derived data. Some need only the original.
I need derived data to be calculated only once and only when I query for it.
The example on the Apollo site seems to imply needing to trigger a mutation first but that seems wrong to me since each component that uses this derived data needs to trigger a mutation first to make sure it's initialized. I don't want to do a query and a mutation everywhere I need data.
So my question is: Can/should I use query resolvers in apollo-link-state or is there some better way of thinking about this?
UPDATE: I think their async example might be what I need but I need to work it through.
Figured it out. Don't know why this wasn't obvious to me to begin with but.... hindsight.
In the end, you just need to define your resolver to return something. The resolver can even make its own queries.
export const getProjectDerived = (_obj, { ProjectId }, { cache }, info) => {
const projQueryRes = cache.readQuery({
query: projQuery,
variables: {
ProjectId
}
})
const newObj = { ...something here... }
return newObj
}
Then just include it in the 'Query' section of the resolvers.
import { getProjectDerived } from './project'
const resolvers = {
Query: {
ProjectDerived: getProjectDerived
}
}
export default resolvers
I have the following situation, my data look like this:
Product
_id: ID
name
en_US: String
nl_NL: String
weight: Number
Now I'd like to make the following GraphQL query:
{
products {
_id
name(locale:"nl_NL")
}
}
This works when adding a resolver to the productType, which returns the right locale based on the given argument. I'd rather not repeat this type + resolver all the time everytime I use this locale structure in my database. So it seems logical to create a localeType, and pass the right argument (locale) to this type, to then resolve the locale there.
For this I'd imagine to need either a Schema Type with no fields (which is not possible afaik):
const localeType = new GraphQLObjectType({
name: 'Locale',
fields: {
resolve: (locale, args) => this[args.locale],
},
});
Or a Scalar Type which accepts arguments.
Are either of these possible in GraphQL currently? And what would the syntax be?
Or any other way to solve this issue?