All Projects → imqueue → graphql-dependency

imqueue / graphql-dependency

Licence: ISC license
Cross service dependencies for GraphQL API with underlying @imqueue services

Programming Languages

typescript
32286 projects

Projects that are alternatives of or similar to graphql-dependency

Typeorm Graphql Loader
A query builder to easily resolve nested fields and relations for TypeORM-based GraphQL servers
Stars: ✭ 47 (+176.47%)
Mutual labels:  resolver
Eslint Import Resolver Babel Module
Custom eslint resolve for babel-plugin-module-resolver
Stars: ✭ 236 (+1288.24%)
Mutual labels:  resolver
documentation-site
This repository contains source for TravelgateX documentation. TravelgateX is a collection of GraphQL APIs for the travel trade.
Stars: ✭ 17 (+0%)
Mutual labels:  graphql-api
C Ares
A C library for asynchronous DNS requests
Stars: ✭ 1,193 (+6917.65%)
Mutual labels:  resolver
Sofie Tv Automation
This is the documentation for the state-based studio automation system Sofie, used in live TV news production by the Norwegian public service broadcaster NRK since September 2018.
Stars: ✭ 155 (+811.76%)
Mutual labels:  resolver
eleventy-load
Resolve dependencies and post-process files in your Eleventy project
Stars: ✭ 28 (+64.71%)
Mutual labels:  loaders
Swagger Parser
Swagger 2.0 and OpenAPI 3.0 parser/validator
Stars: ✭ 710 (+4076.47%)
Mutual labels:  resolver
react-native-animated-loader
🍭 A React Native Loader Component which uses Airbnb's Lottie for beautiful loader animations.
Stars: ✭ 165 (+870.59%)
Mutual labels:  loaders
Hotchocolate
Welcome to the home of the Hot Chocolate GraphQL server for .NET, the Strawberry Shake GraphQL client for .NET and Banana Cake Pop the awesome Monaco based GraphQL IDE.
Stars: ✭ 3,009 (+17600%)
Mutual labels:  resolver
react-apollo-form
Build React forms based on GraphQL APIs.
Stars: ✭ 195 (+1047.06%)
Mutual labels:  graphql-api
Graphql Mongoose Loader
GraphQL Mongoose Loader helpers
Stars: ✭ 98 (+476.47%)
Mutual labels:  resolver
Prance
Resolving Swagger/OpenAPI 2.0 and 3.0 Parser
Stars: ✭ 133 (+682.35%)
Mutual labels:  resolver
DotNetGraphQL
A sample demonstrating how to create a GraphQL Backend in .NET and consume it from a .NET mobile app created using Xamarin
Stars: ✭ 78 (+358.82%)
Mutual labels:  graphql-api
Unbound
Unbound is a validating, recursive, and caching DNS resolver.
Stars: ✭ 1,103 (+6388.24%)
Mutual labels:  resolver
jurl
Fast and simple URL parsing for Java, with UTF-8 and path resolving support
Stars: ✭ 84 (+394.12%)
Mutual labels:  resolver
Domain
A DNS library for Rust
Stars: ✭ 37 (+117.65%)
Mutual labels:  resolver
Kuberesolver
Grpc Load Balancer with Kubernetes resolver
Stars: ✭ 241 (+1317.65%)
Mutual labels:  resolver
graphql-pokeapi
🔴 The Unofficial GraphQL for PokeAPI
Stars: ✭ 137 (+705.88%)
Mutual labels:  graphql-api
redux-autoloader
A higher order component for declarative data loading in React and Redux.
Stars: ✭ 56 (+229.41%)
Mutual labels:  data-loader
strapi-graphql-documentation
Collections of queries and mutations that hopefully help you in a Strapi project powered by GraphQL API 🚀
Stars: ✭ 45 (+164.71%)
Mutual labels:  graphql-api

@imqueue/graphql-dependency

Build Status codebeat badge Coverage Status David David Known Vulnerabilities License

Cross service GraphQL dependency loading during query calls for @imqueue ecosystem.

Install

npm i --save @imqueue/graphql-dependency

Usage

This module allows to describe cross-service dependencies and fetch user requested data in an optimal manner. Let's imagine we have 2 micro-services serving User and Company data respectively. Let's assume User can be a team member of the Company. As well as Company can have User as an owner.

On GraphQL API level it may be represented by a following schema:

type User {
    id: ID!
    name: String!
    email: String!
    phone: String!
    ownerOf: [Company]
    memberOf: [Company]
}
type Company {
    id: ID!
    name: String!
    description: String!
    ownerId: Int!
    owner: User
    members: [User]
}

Now we have a query which can fetch a user with all related data, like this:

query user(id: "VXNlcjox") {
    id
    name
    email
    phone
    ownerOf {
        id
        name
        members {
            id
            name
            phone
        }
    }
    memberOf {
        id
        name
        owner {
            id
            name
            email
            phone
        }
    }
}

As seen from such query we would need to implement resolver recursively loading companies data for user and user data for companies.

With this module it's possible to resolve such dependencies automatically and fetch data in a most efficient way using caching and minimizing number of request by defining the dependencies between entities and their loaders and initializers.

import { Dependency } from '@imqueue/graphql-dependency';
import {
    GraphQLID,
    GraphQLList,
    GraphQLNonNull,
    GraphQLObjectType,
    GraphQLString,
} from 'graphql';
import { globalIdField } from 'graphql-relay';
// we referring @imqueue based clients here
import { userClient, companyClient } from '../clients';

/**
 * User type definition
 */
export const User = new GraphQLObjectType({
    name: 'User',
    fields: () => ({
        id: globalIdField(
            User.name,
            (user: userClient.User) => user.id + '',
        ),
        name: {
            type: new GraphQLNonNull(GraphQLString),
            resolve: (user: userClient.User) => user.name,
        },
        phone: {
            type: new GraphQLNonNull(GraphQLString),
            resolve: (user: userClient.User) => user.name,
        },
        email: {
            type: new GraphQLNonNull(GraphQLString),
            resolve: (user: userClient.User) => user.name,
        },
        ownerOf: {
            type: new GraphQLList(Company),
            resolve: (user: userClient.user) => user.name
        }
    }),
});

/**
 * Defining user type loader.
 * Loader defines how the entity should be loaded when it is a dependency of
 * another object. Fo example, When company needs to load a user it will call
 * this loader to fill the fields of User type. 
 */
Dependency(User).defineLoader(async (
    context: any,
    filter: any,
    fields: any,
): Promise<Array<Partial<userClient.User>>> =>
    // meaning context contain initialized user service client reference
    // BTW loader could implement any functionality fetching users list by
    // a given filter returning requested user fields
    // @see https://github.com/Mikhus/graphql-fields-list library, for example,
    // to extract fields map input from graphql request info object
    // Filter would contain data constructed from parent objects data set
    // using the Dependency filtering options defined in the require() calls.
    await context.user.list(filter, fields),
);

/**
 * Company type definition
 */
export const Company = new GraphQLObjectType({
    name: 'Company',
    fields: () => ({
        id: globalIdField(
            Company.name,
            (company: companyClient.Company) => company.id + '',
        ),
        name: {
            type: new GraphQLNonNull(GraphQLString),
            resolve: (company: companyClient.Company) => company.name,
        },
        description: {
            type: new GraphQLNonNull(GraphQLString),
            resolve: (company: companyClient.Company) => company.description,
        },
        ownerId: {
            type: new GraphQLNonNull(GraphQLID),
            resolve: (company: companyClient.Company) => company.ownerId,
        },
        owner: {
            type: User,
            resolve: (company: companyClient.Company) => company.owner,
        },
        members: {
            type: new GraphQLList(User),
            resolve: (company: companyClient.Company) => company.members,
        },
    }),
});

/**
 * Defining company type loader
 */
Dependency(Company).defineLoader(async (
    context: any,
    filter: any,
    fields: any,
): Promise<Array<Partial<companyClient.Company>>> =>
    // meaning context contain initialized company service client reference
    await context.company.list(filter, fields),
);

/**
 * Describing dependencies
 */
Dependency(Company).require(User, () => ({
    as: Company.getFields().owner,
    filter: {
        // here we assume that user loader implements fetching users list
        // by a filter containing list of user identifiers
        [User.getFields().id.name]: Company.getFields().ownerId,
    },
}), () => ({
    as: Company.getFields().members,
    filter: {
        // here we assume that user loader implements fetching list of users
        // by a filter containing list of related company identifiers
        'relatedCompanyIds': Company.getFields().id,
    },
}));

Dependency(User).require(Company, () => ({
    as: User.getFields().memberOf,
    filter: {
        'relatedMemberIds': User.getFields().id,
    },
}), () => ({
    as: User.getFields().ownerOf,
    filter: {
        [Company.getFields().ownerId]: User.getFields().id,
    },
}));

With this setup we assume that user and company loaders implements data fetching by a defined dependency requirement filters. @imqueue ecosystem provides a straightforward way dealing with filters/fields fetched from a user request, or you can implement it any suitable way, for example having loaders implementation which directly makes database or key-value storage calls without the need to create service layer.

Then on query implementation resolver we would act as this:

async function resolve(
    source: any,
    args: any,
    context: any,
    info: GraphQLResolveInfo,
) {
    const fields = fieldsMap(info);
    const user = context.user.find(fromGlobalId(args.id).id);

    if (user) {
        // this call will fetch all dependent data and map it to a resulting
        // user object (modifying it)
        await Dependency(User).load([user], context, fields);
    }

    // now we are safe to return all the source data requested
    return user;
}

Dependency loader will do all the job calling the minimum amount of requests required to fill the result data. If end user created a request containing recursive nesting which falls into fetching process of the same data recursively it will end up in a data mapping without an additional calls for each nesting levels. Most of the data are not copied and is mapped by references, so the memory footprint will be kept on minimal level as well.

License

ISC

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].