Forem: Tushar Khubani

A small web app to check vaccine availability throughout India

Tushar Khubani — Tue, 18 May 2021 16:32:50 +0000

Links

The reason I made this small web app was to simplify the way availability is shown.
The endpoint being consumed returns the vaccine availability for 7 days from the date selected.
Feel free to share this with your friends and family for booking their vaccine slot accordingly.

MongoDB Aggregation pipeline stages to the rescue!

Tushar Khubani — Thu, 09 May 2019 08:27:01 +0000

Imagine a situation where you have a schema with a one to many relationship

//customer schema
const customerSchema = new mongoose.Schema(
  {
    name: {
      type: String
    },
    email: {
      type: String
    }
  }
);

//consumable's schema
const consumableSchema = new mongoose.Schema(
  {
    name: {
      type: String
    },
    email: {
      type: String
    }
  }
);

//payments schema
const consumableSchema = new mongoose.Schema(
  {
    amount: {
      type: Number,
      required:true
    },
    paid:{
        type:Number,
        required:true
    }
    customer: {
      type: mongoose.Schema.Types.ObjectId,
      ref: "Customer",
      required: true
    },
    consumable : {
       type: mongoose.Schema.Types.ObjectId,
      ref: "Consumable",
      required: true
    }
  }
);

So now if you're supposed to get the sum of the paid amount for a customer, mongoose aggregation pipelines are a great and efficient way to do so.
The way you get the sum is as follows

Match the customer id
group by id (if id not required just use null)
get sum of paid/amount

//query to get the above result
const {customerID} = args;
const result = await Payment.aggregate([
    {
      $match: { customer: customerID }
    },
    {
      $group: {
        _id: null,
        paidTotal: { $sum: "$paid" },
        amountTotal: { $sum: "$amount" }
      }
    }
  ]);
  console.log(result)
  // logs [{ _id: null, amount: 800, paid: 600 }] which is an array of objects.

Now we come to consumables, consider consumables as food items [burger,pizza,fries...etc].
Your customer requires a statistical view of the consumables being sold/consumed daily/monthly/quarterly/yearly.
In that scenario the query would look something like this

const { from, to } = args;

  const result = await Payment.aggregate([
    {
      $match: { createdAt: { $gte: from, $lt: to } }
    },
    {
      $lookup: {
        from: "consumables",
        localField: "consumable",
        foreignField: "_id",
        as: "consumable"
      }
    },
    {
      $unwind: "$consumable"
    },
    {
      $replaceRoot: { newRoot: "$consumable" }
    },
    {
      $group: {
        _id: "$_id",
        name: { $first: "$name" },
        count: { $sum: 1 }
      }
    },
    { $sort: { name: 1 } } // can use count for sorting as well
  ]);
  console.log(result);
  //logs 
  [
      { _id: 5ca5c352ccf2241169f9c8ab, name: 'Burger', count: 30 },
      { _id: 5ca5c367ccf2241169f9c8ad, name: 'Fries', count: 24 },
      { _id: 5ca5c361ccf2241169f9c8ac, name: 'Pizza', count: 15 }
  ]

Here we use $lookup(aggregation) to get the relationship from consumables to payment (one to many).

Here "from" indicates the schema that we are referring to, in this case we are referring "Consumable schema from Payment schema".
The local field refers to the name of field which we are using to relate to the Consumable schema, which is consumable field in Payments schema
The foreign field refers to the field in the schema which we are trying to relate to, which is Consumable Schema, and the field is _id
and as can be understood as a constant which stores the result from the relationship query.
- The result from the lookup aggregation in this case is an array, we deconstruct the array using $unwind(aggregation).
- We then change the root to $consumable, using the $replaceRoot(aggregation), although this isn't required, but makes the query look prettier. This replaces the root of the query and moves $consumable to the topmost level and replaces all fields. In case you don't want to use $replaceRoot you can always use it like this name: "$$ROOT.consumable.name", check how this compares to the code name: {$first:"$name"}, looks neat.

To conclude, you could always use mongoose aggregation pipeline stages for generating statistics, or any similar situations. An example would be generating statistics for user signups based on time/day/date/month/quarter/year.

Hope you had patience to read all of this :)

Using GraphQL schema directives for role based authorization

Tushar Khubani — Tue, 19 Mar 2019 11:43:57 +0000

When working on a graphql based api backend using node.js, if you stumble across role based authorization there are plenty ways of authorizing the logged in user.

You could keep the authorization logic completely separate from graphql(in a controller), you could write the logic in the resolvers itself(increases the amount of code in resolvers) or to keep the code clean and understandable, write GraphQL custom schema directives.

So here is how you would write a custom schema directive in graphql, for authorizing particular roles.

//HasRoleDirective.js

import { SchemaDirectiveVisitor } from "apollo-server-express";
import {
  GraphQLDirective,
  DirectiveLocation,
  GraphQLList,
  defaultFieldResolver
} from "graphql";
import { ensureAuthenticated } from "../controllers/authController";
import { AuthorizationError } from "../errors";

class HasRoleDirective extends SchemaDirectiveVisitor {
  static getDirectiveDeclaration(directiveName, schema) {
    return new GraphQLDirective({
      name: "hasRole",
      locations: [DirectiveLocation.FIELD_DEFINITION],
      args: {
        roles: {
          type: new GraphQLList(schema.getType("Role"))
        }
      }
    });
  }
  visitFieldDefinition(field) {
    const { resolve = defaultFieldResolver } = field;
    const roles = this.args.roles;
    field.resolve = async function(...args) {
      const [, , context] = args;
      await ensureAuthenticated(context);
      const userRoles = context.me.role;

      if (roles.some(role => userRoles.indexOf(role) !== -1)) {
        const result = await resolve.apply(this, args);
        return result;
      }
      throw new AuthorizationError({
        message: "You are not authorized for this resource"
      });
    };
  }
}
export default HasRoleDirective;

First we declare the directive name and the valid arguments that it accepts, when accepting arguments.
later in the field definition visitFieldDefinition(field), where the logic is to be described, we accept arguments, extract contexrt from the args, the function call ensureAuthenticated(context) is to veirfy the jwtToken from the context, I have included the user's role in the jwt token.
So the HasRole directive is declared and ready to use. To use you need to pass the directives to your graphql config and declare it in the typeDefinition as follows

// GraphQL Config
const schemaDirectives = { hasRole: HasRoleDirective };
const server = new ApolloServer({
  typeDefs,
  resolvers,
  schemaDirectives,
  ...context
});

//typedefinitions
import { gql } from "apollo-server-express";
export default gql`
  directive @hasRole(roles: [String!]) on FIELD_DEFINITION | FIELD
  scalar Date

  type Query {
    _: String
  }
  type Mutation {
    _: String
  }
`;

this way you will be able to use the custom schema directive in your typeDefs
example on how to use the custom schema directive:

import { gql } from "apollo-server-express";

export default gql`
  extend type Query {
    businesses: [Business!] @hasRole(roles: [THIS_SUPER_ADMIN])
    business(id: ID!): Business @hasRole(roles: [THIS_ADMIN, THIS_SUPER_ADMIN])
  }
  extend type Mutation {
    businessUpdate(name: String!): Business!
      @hasRole(roles: [THIS_ADMIN, THIS_SUPER_ADMIN])
  }
  type Business {
    id: ID!
    name: String!
  }
`;

Another example, to verify if a user is authenticated

//AuthDirective.js
import { SchemaDirectiveVisitor } from "apollo-server-express";
import { defaultFieldResolver } from "graphql";
import { ensureAuthenticated } from "../controllers/authController";

class AuthDirective extends SchemaDirectiveVisitor {
  visitFieldDefinition(field) {
    const { resolve = defaultFieldResolver } = field;

    field.resolve = async function(...args) {
      const [, , context] = args;
      await ensureAuthenticated(context);
      return resolve.apply(this, args);
    };
  }
}
export default AuthDirective;
//passing to graphql config
const schemaDirectives = { auth: AuthDirective };
const server = new ApolloServer({
  typeDefs,
  resolvers,
  schemaDirectives,
  ...context
});

//declaration in typeDefinitions
import { gql } from "apollo-server-express";
export default gql`
  directive @auth on FIELD_DEFINITION
  scalar Date

  type Query {
    _: String
  }
  type Mutation {
    _: String
  }
`;
//typedefinitions usage
`extend type Query {
    payments(
      customer: ID
      status: String
      cursor: String
      limit: Int
    ): PaymentCollection! @auth
  }
  `

If you need to apply more than one directive to a query/mutation NOTE: the direction you write directives in graphql queries is from right to left, the right most directive is resolved first then the one to its left is resloved.
so say if you have this

`extend type Query {
    payments(
      customer: ID
      status: String
      cursor: String
      limit: Int
    ): PaymentCollection! @hasRole(roles: [THIS_ADMIN, THIS_SUPER_ADMIN]) @auth
  }`

the auth directive is resolved first and the hasRoles is resolved after the auth directive. Say the auth directive fails the hasRoles directive is never reached.

I'm still learning a lot in GraphQL, if there are any improvements or mistakes in the code above please do drop a comment,
its always better to learn from the mistakes we make :)