Unrestricted normalization depth, arguments, filtering, sorting, and paginating without special logic custom to each ORM Entity

This article assumes you have a basic grasp of  NestJS as well as how it is implemented with TypeORM and the  NestJS GraphQL package. If you are looking for how to get a basic project up and running take a look the the docs posted in the links. This article also uses a Code-First approach, if you aren’t sure what that means this is a good rundown of benefits and differences over a Schema-First approach.

What, why, and for whom

GraphQL is quickly becoming a staple of the future API, it provides a new and much more dynamic perspective on how the data layer of your application(s) should be consumed and developed. Using a GraphQL-First approach, every feature revolves around a GraphQL schema, allowing your front-end team and your API team work independently knowing that the two pieces will work together when they are ready. Rather than simple REST API endpoints that resolve the same object structure (and potentially just look-ups to other endpoints in lieu of actual children) we can provide all the properties and relationships we want in a single request.

In my experience with NestJS and TypeORM the integration of GraphQL is a little funky. First of all, the structure and depth of the query is only provided to your custom resolver in a semi-enigmatic object (@Info() info: GraphQLResolveInfo), and there are no clear pathways to handling the selected attributes inside of a query which is a problem if we want to structure the TypeORM query to meet the depth requirements of the incoming GraphQL query.

This package’s goal is to bridge the gap between your GraphQL and TypeORM implementation. Rather than writing a custom tailored resolver that can only go _n _layers deep or writing your own custom sorting, filtering, and pagination handling, PerchQueryBuilder provides all of those features ignorant of the literal structure of your entity, allowing you easy and simple integration with GraphQL. Since this package is merely an attempt to translate GraphQL into TypeORM, the queries are handled as though they are a direct translation to your ORM entities property and relationship names, since it relies on TypeORM’s definitions of your entities. For instance, if you had an entity named Book, with a many-to-one relationship to an Author entity called author you would need to specify _author _as a selected attribute (as well as any of the properties beneath Author) to the query in order to retrieve it.

#graphql #typeorm #programming #typescript #nestjs