GraphQL

GraphQL is basically RPC with a default procedure providing a query language

Advantages / Benefits Over REST: Avoid overmatching - Get only fields that you need Avoid under-fetching - Less chatty - Under-fetching generally means that a specific endpoint doesn’t provide enough of the required information. The client will have to make additional requests to fetch everything it needs. Ex: Fetching posts for every user. In traditional REST, we first GET User resource and then GET post for the user. Subscribe operation in addition to CRUD where clients can receive real time msgs from server.

Disadvantages Caching - No built in caching like browser caching in HTTP Additional overheads for simple queries Rigidness of queries/types

 

• Queries - To fetch data
• Mutation - To mutate - create/upd/del data
• Resolver - Function to communicate with the data source  
• Schema definitions is the first and important step in defining the GraphQL API
• Ex:

schema {                            // needed in every schema
  query: Query          // defines the type that shud be called for queries
  mutation: Mutation 
} 
type Query { 
  getTodos: [Todo]  // defines the resolver fn to be called and Todo is the item/array that will be returned
} 
type Mutation { 
  addTodo(id: ID!, name: String, description: String, priority: Int, status: TodoStatus): Todo  // defines the input params for resolver and Todo is the output obj
} 
type Todo { 
  id: ID!  // ! Means mandatory field 
  name: String 
  description: String 
  priority: Int 
  status: TodoStatus  //custom data type defined below
} 
enum TodoStatus { 
  done 
  pending 
}

 

• Next, we can define queries that adhere to the schema definition….for instance,

query getAToDo {   // name of the query
  getToDos (id : "82eeb8d3-6923-49fe-883d-dc60aff0b2bf") {    //Reference the query resolver function and its input based on schema definition
    id                // Fields to request in response.
    name
    description
  }
}

• Similarly mutations can be defined like below,

mutation createToDos($createtodosinput: CreateToDosInput!) {
  createToDos(input: $createtodosinput) {
    id
    name
    description
    priority
  }
}

Query variables:

{
  "createtodosinput": {
    "name": "Meet with client",
    "description": "Work",
    "priority": 5
  }
}

Resolver Function Responsible for fetching data from backend. 4 args passed to resolver - root - Result of previous/parent type or resolver call - useful when child resolver executes args - Parameter of the query. For instance, in ex above, id is available thru args context - An object that gets passed through the resolver chain that each resolver can write to and read from. Not to be used as cache though it is mutable. info - An AST representation of the query or mutation (used rarely).

Project:

• Clone the server — https://stash.aexp.com/stash/projects/ONE-DATA/repos/one-graphql-server/browse
• npm install and then invoke the server as NODE_ENV=development npm run start:dev
• To define a new query
  • Create new type within src/graphql/types. Ex: create Dispute folder and then define the type in schema.graphql i.e the data types.
  • Add query object in src/graphql/types/Query/schema.graphql
  • Add the resolver function in src/graphql/types/Query/resolver.js
  • The resolver function will refer to context.api.readCardMemberDisputes method to fetch the data and then will map the results appropriately.
  • Create new function within /src/graphql/apis that will make the API call. Exx: readCardMemberDisputes.js
  • Add the mocking response within the /src/mocking/scenarios.js which would provide the response to the function that makes API call. Also update index.js within the same dir to reference the new function

**Requirement: **

1. Get a count of cases by status i.e. open, closed, All
2. Find if any case exists for a CM - true/false flag
3. Get list of disputed transactions for a CM & supp for 2 billing cycles (unbilled & current) I.e. fetch cases that have txns with billing cycle as 0 or -1.

Future- Current MYCA - Get list of all cases by acct & supp + logic for open/close, msgs, statuses etc

Solution options:

1. GraphQL server

   1. Queries Triumph API & GDM DB - One data composite function to call Triumph API, One data SOR function to query GDM DB.
   2. define types for getting count by statuses and to check if case exists Pros & cons: +Can support req 1/2 & 3 by defining appropriate types. +Can support future MYCA need -Requires clients to have a GQL client to call API??

2. One data Buss Fn -

   1. Composite SOR to fetch triumph data via API
   2. SOR to fetch GDM data from DB
   3. Aggregate results Pros & cons: -Will need different request types and custom logic to support req 1 & 3 (2 can be combined with 1) -May need additional req type for MYCA or other customers in future