I am trying to make structure for GraphQl resolvers, but a bit stuck.
Imagine that we have different sale type entities
type Sale {
name: String
value: Float
type: Int
}
Currently we have a query which gets all the sales by type and compare them for different date ranges
type SaleResult {
name: String
main_value: Float
compare_value: Float
difference: Float
type: Int
}
input DateParamsInput {
start: DateTime!
end: DateTime!
}
input SomeFilterInput {
dateRangeMain: DateParamsInput
dateRangeCompare: DateParamsInput
type: [Int]
}
Query {
getSales(filter: SomeFilterInput) [SaleResult]
}
and now we were requested to add a switcher to grab data either without compare value or with it. We can add new query but I am trying to find a way to have single query for both cases
There is a solution, how I see it
Query {
getSales2(type: [Int]) {
sale {
name
type
diff(mainRange, compareRange) {
main_value
compare_value
diff
}
value(mainRange)
}
}
}
In this case we will have 2 nested resolvers: diff and value. The first one can return data with compare value and another one for single value
Another way
Query {
getSales2(type: [Int], mainRange) {
sale {
name
type
value
compare(compareRange) {
value
diff
}
}
}
}
but in this case we have to have value before compare resolver starts and I am not sure this is the working approach
Since I have no one to validate this, I am asking for your help. Do you have any thoughts?
Related
I want to see output in graphql-playground of mutations which I don't know how to do. Code is below.
type Query {
""" Gets single referral program"""
program:Program
setting(level_id:Int!): Setting
}
type Mutation {
"""Define loyalty program for a club"""
define_program(input:DefineProgram): Program
"""Club level loyalty program configuration"""
config_program(input:ProgramConfig): Setting
get_individual_code(input:Individual): String
get_group_code(input:Group): String
}
type Program {
id: String
name: String
referral_level_id:Int
enabled:Boolean
}
input DefineProgram {
name: String!
type:ReferralType!
referral_level_id:Int!
enabled:Boolean = true
userid: Int
}
input ProgramConfig {
program_id: Int!
level_id:Int!
type:CodeType!
expirydays:String!
validity:Int!
limit:Int!
userid:Int
}
input Individual {
member_id:Int!
days_to_expire:Int!
first_name:String!
last_name:String!
email:String!
userid:Int
}
input Group {
member_id: Int!
days_to_expire:Int!
people:Int!
userid:Int
}
input Filter {
program_id: Int!
level_id: Int!
}
type Setting {
program_id: Int
program_name:String
level_id:Int
tier:String
type:CodeType
expirydays:String
validity:Int
limit:Int
}
enum CodeType {
NUMERIC
ALPHA_NUMERIC
}
enum ReferralType {
INDIVIDUAL,
GROUP,
BOTH
}
Can anyone tell me how to write for all mutations to get data in graphql-playground.
Help if anyone can.
GraphQL playground will actually give you autocomplete capabilities. It sounds like you're just starting out with consuming GraphQL, though, so I would recommend you start with the learning queries from graphql.org, and then once you're comfortable there, you should be able to put together queries / mutations for your specific examples.
I have a product and items
Product:
{
id: Int
style_id: Int
items: [items]
}
Items:
{
id: Int
product_id: Int
size: String
}
I want to query products but only get back products that have an item with a size.
So a query could look like this:
products(size: ["S","M"]) {
id
style_id
items(size: ["S","M"]) {
id
size
}
}
But it seems like there should be a way where I can just do
products {
id
style_id
items(size: ["S","M"]) {
id
size
}
}
And in the resolver for the products I can grab arguments from the nested query and use them. In this case add the check to only return products that have those sizes. This way I have the top level returned with pagination correct instead of a lot of empty products.
Is this possible or atleast doing it the other way around:
products(size: ["S","M"]) {
id
style_id
items {
id
size
}
}
And sending the size argument down to the items resolver? Only way I know would be through context but the one place I found this they said that it is not a great idea because context spans the full query in all depths.
I agree with #DenisCappelini's answer. If possible, you can create a new type which represents only Products that have an Item.
However, if you don't want to do that, or if you're just interested in general about how a top-level selector can know about arguments on child selectors, here is a way to do that:
There are 2 ways to do it.
To do this:
products {
id
style_id
items(size: ["S","M"]) {
id
size
}
}
In graphql, resolvers have this signature:
(obj, args, context, info) => {}
The 4th argument, info, contains information about the entire request. Namely, it knows about arguments on the child selectors.
Use this package, or a similar one because there are others, to parse info for you: https://www.npmjs.com/package/graphql-parse-resolve-info
The above is quite a lot of work, so if you want to do this instead:
products(size: ["S","M"]) {
id
style_id
items {
id
size
}
}
Then in your resolver for products, you need to also return size.
Suppose this is your resolver for products:
(parent, args) => {
...
return {
id: '',
style_id: ''
}
}
Modify your resolver to also return size like this:
(parent, args) => {
...
return {
id: '',
style_id: '',
size: ["S", "M"]
}
}
Now in your resolve for products.items, you will have access to the size, like this:
(product, args) => {
const size = product.size
}
I found this useful #reference
//the typedef:
type Post {
_id: String
title: String
private: Boolean
author(username: String): Author
}
//the resolver:
Post: {
author(post, {username}){
//response
},
}
// usage
{
posts(private: true){
_id,
title,
author(username: "theara"){
_id,
username
}
}
}
IMO you should have a ProductFilterInputType which is represented by a GraphQLList(GraphQLString), and this resolver filters the products based on this list.
import { GraphQLList, GraphQLString } from 'graphql';
const ProductFilterInputType = new GraphQLInputObjectType({
name: 'ProductFilter',
fields: () => ({
size: {
type: GraphQLList(GraphQLString),
description: 'list of sizes',
}
}),
});
Hope it helps :)
these are few tweaks you can add and make your design better and also filter items properly.
1- change your product schema:
{
id: Int! # i would rather to use uuid which its type is String in gql.
styleId: Int
items: [items!] # list can be optional but if is not, better have item. but better design is below:
items(after: String, before: String, first: Int, last: Int, filter: ItemsFilterInput, orderBy: [ItemsOrderInput]): ItemsConnection
}
2- have a enum type for sizes:
enum Size {
SMALL
MEDIUM
}
3- change item schema
{
id: Int!
size: Size
productId: Int
product: Product # you need to resolve this if you want to get product from item.productId
}
4- have a filter type
input ItemFilterInput {
and: [ItemFilterInput!]
or: [ItemFilterInput!]
id: Int # you can use same for parent id like productId
idIn: [Int!]
idNot: Int
idNotIn: [Int!]
size: Size
sizeIn: [Size!]
sizeNotIn: [Size!]
sizeGt: Size # since sizes are not in alphabetic order and not sortable this wont be meaningful, but i keep it here to be used for other attributes. or you can also trick to add a number before size enums line 1SMALL, 2MEDIUM.
sizeGte: Size
sizeLt: Size
sizeLte: Size
sizeBetween: [Size!, Size!]
}
5- then create your resolvers to resolve the below query:
{
product {
items(filter: {sizeIn:[SMALL, MEDIUM]}) {
id
}
}
}
# if returning `ItemsConnection` resolve it this way:
{
product {
id
items {
edges {
node { # node will be an item.
id
size
}
}
}
}
}
Relay has a very good guideline to design a better schema.
https://relay.dev/
I also recommend you to add edges and node and connection to your resolvers to be able to add cursors as well. having product {items:[item]} will limit your flexibility.
We are using GraphQL as a query language for a data aggregation engine.
I am looking for ideas to represent simple (or complex) arithmetic calculation functions in GraphQL referring to existing types/attributes defined in a schema, and can be used over existing attributes.
I am looking into Custom scalars and Directives
Example -
{
item{
units
price_per_unit
market_price: function:multiply(units, price_per_unit)
market_price_usd: function:usdPrice(units, price_per_unit, currency)
}
}
where function:multiply is already defined in the GraphQL schema as a type
functions {
multiply(operand 1, operand2) {
result
}
usdPrice(operand1, operand2, currency) {
result: {
if(currency == GBP) {
operand1 * operand2 * .76
}
{
}
internally resolver will multiply operand 1 and operand 2 to create result.
This isn't something GraphQL is especially good at. By far the easiest thing to do will be to retrieve the individual fields and then do the computation on the client, something like
data.item.forEach((i) => { i.total_price = i.units * i.price_per_unit });
In particular, there's no way to run any sort of "subquery" in GraphQL. Given a "multiply" function like you've shown there's no GraphQL syntax that will let you "call" it with any particular inputs.
If you think the specific computed values are common enough, you can also add them to the GraphQL schema, and compute them server-side if requested using a custom resolver function.
type Item {
units: Int!
pricePerUnit: CurrencyValue!
# computed, always units * pricePerUnit
marketPrice: CurrencyValue!
}
type CurrencyValue {
amount: Float!
currency: Currency!
# computed, always amount * currency { usd }
usd: Float!
}
type Currency {
code: String!
"1 currency = this many US$"
usd: Float!
}
allowing queries like
{
item {
marketPrice { usd }
}
}
Using facebook's reference library, I found a way to hack generic types like this:
type PagedResource<Query, Item> = (pagedQuery: PagedQuery<Query>) => PagedResponse<Item>
interface PagedQuery<Query> {
query: Query;
take: number;
skip: number;
}
interface PagedResponse<Item> {
items: Array<Item>;
total: number;
}
function pagedResource({type, resolve, args}) {
return {
type: pagedType(type),
args: Object.assign(args, {
page: { type: new GraphQLNonNull(pageQueryType()) }
}),
resolve
};
function pageQueryType() {
return new GraphQLInputObjectType({
name: 'PageQuery',
fields: {
skip: { type: new GraphQLNonNull(GraphQLInt) },
take: { type: new GraphQLNonNull(GraphQLInt) }
}
});
}
function pagedType(type) {
return new GraphQLObjectType({
name: 'Paged' + type.toString(),
fields: {
items: { type: new GraphQLNonNull(new GraphQLList(type)) },
total: { type: new GraphQLNonNull(GraphQLInt) }
}
});
}
}
But I like how with Apollo Server I can declaratively create the schema. So question is, how do you guys go about creating generic-like types with the schema language?
You can create an interface or union to achieve a similar result. I think this article does a good job explaining how to implement interfaces and unions correctly. Your schema would look something like this:
type Query {
pagedQuery(page: PageInput!): PagedResult
}
input PageInput {
skip: Int!
take: Int!
}
type PagedResult {
items: [Pageable!]!
total: Int
}
# Regular type definitions for Bar, Foo, Baz types...
union Pageable = Bar | Foo | Baz
You also need to define a resolveType method for the union. With graphql-tools, this is done through the resolvers:
const resolvers = {
Query: { ... },
Pageable {
__resolveType: (obj) => {
// resolve logic here, needs to return a string specifying type
// i.e. if (obj.__typename == 'Foo') return 'Foo'
}
}
}
__resolveType takes the business object being resolved as its first argument (typically your raw DB result that you give GraphQL to resolve). You need to apply some logic here to figure out of all the different Pageable types, which one we're handling. With most ORMs, you can just add some kind of typename field to the model instance you're working with and just have resolveType return that.
Edit: As you pointed out, the downside to this approach is that the returned type in items is no longer transparent to the client -- the client would have to know what type is being returned and specify the fields for items within an inline fragment like ... on Foo. Of course, your clients will still have to have some idea about what type is being returned, otherwise they won't know what fields to request.
I imagine creating generics the way you want is impossible when generating a schema declaratively. To get your schema to work the same way it currently does, you would have to bite the bullet and define PagedFoo when you define Foo, define PagedBar when you define Bar and so on.
The only other alternative I can think of is to combine the two approaches. Create your "base" schema programatically. You would only need to define the paginated queries under the Root Query using your pagedResource function. You can then use printSchema from graphql/utilities to convert it to a String that can be concatenated with the rest of your type definitions. Within your type definitions, you can use the extend keyword to build on any of the types already declared in the base schema, like this:
extend Query {
nonPaginatedQuery: Result
}
If you go this route, you can skip passing a resolve function to pagedResource, or defining any resolvers on your programatically-defined types, and just utilize the resolvers object you normally pass to buildExecutableSchema.
I have a Apollo GraphQL server talking to an API returning responses with roughly the following structure:
{
"pagination": {
"page": 1,
// more stuff
},
sorting: {
// even more stuff
},
data: [ // Actual data ]
}
This structure is going to be shared across pretty much all responses from this API, that I'm using extensively. data is going to be an array most of the time, but can also be an object.
How can I write this in an efficient way, so that I don't have to repeat all these pagination and sorting fields on every data type in my schemas?
Thanks a lot!
I've sorted your problem by creating a lib called graphql-s2s. It enhances your schema by adding support for type inheritance, generic types and metadata. In your case, creating a generic type for your Paginated object could be a viable solution. Here is an example:
const { transpileSchema } = require('graphql-s2s')
const { makeExecutableSchema } = require('graphql-tools')
const schema = `
type Paged<T> {
data: [T]
cursor: ID
}
type Node {
id: ID!
creationDate: String
}
type Person inherits Node {
firstname: String!
middlename: String
lastname: String!
age: Int!
gender: String
}
type Teacher inherits Person {
title: String!
}
type Student inherits Person {
nickname: String!
questions: Paged<Question>
}
type Question inherits Node {
name: String!
text: String!
}
type Query {
students: Paged<Student>
teachers: Paged<Teacher>
}
`
const executableSchema = makeExecutableSchema({
typeDefs: [transpileSchema(schema)],
resolvers: resolver
})
I've written more details about this here (in Part II).
When you define your schema, you will end up abstracting out pagination, sorting, etc. as separate types. So the schema will look something like:
type Bar {
pagination: Pagination
sorting: SortingOptions
data: BarData # I'm an object
}
type Foo {
pagination: Pagination
sorting: SortingOptions
data: [FooData] # I'm an array
}
# more types similar to above
type Pagination {
page: Int
# more fields
}
type SortingOptions {
# more fields
}
type BarData {
# more fields
}
So you won't have to list each field within Pagination multiple times regardless. Each type that uses Pagination, however, will still need to specify it as a field -- there's no escaping that requirement.
Alternatively, you could set up a single Type to use for all your objects. In this case, the data field would be an Interface (Data), with FooData, BarData, etc. each implementing it. In your resolver for Data, you would define a __resolveType function to determine which kind of Data to return. You can pass in a typename variable with your query and then use that variable in the __resolveType function to return the correct type.
You can see a good example of Interface in action in the Apollo docs.
The downside to this latter approach is that you have to return either a single Data object or an Array of them -- you can't mix and match -- so you would probably have to change the structure of the returned object to make it work.