Offset Paging Strategy [BREAKING CHANGE]
In previous versions ofnestjs-query the OFFSET paging strategy returned an array of nodes, this proved to not be extensible, especially when wanting to expose other attributes such as totalCount, or paging meta such has hasNextPage or hasPreviousPage.
In v0.23.0 the graphql response now returns an OffsetConnection that looks like the following
Total Count with OFFSET Strategy
In previous versions of the nestjs-query theenableTotalCount option only worked with the CURSOR paging strategy. In v0.23.0 the enableTotalCount option now also works with the OFFSET paging strategy.
When enableTotalCount is set to true the following graphql schema will be generated
Relation Decorator Changes [BREAKING CHANGE]
In previous versions ofnestjs-query there were four relation decorators @Relation, @FilterableRelation, @Connection, and @FilterableConnection all four of the decorators have been changed to be more explicit in naming to be clear in what they are doing.
In v0.23.0 the decorators have been renamed to be more explicit.
@Relation- A relation that is a single value (one-to-one, many-to-one)@FilterableRelation- A@Relationthat enables filtering the parent by fields of the relationDTO.@UnPagedRelation- An array of relations (e.g, many-to-many, one-to-many) that returns all the related records.@FilterableUnPagedRelation- An@UnPagedRelationthat enables filtering the parent by fields of the relationDTO.@OffsetConnection- A connection that represents a collection (e.g, many-to-many, one-to-many) that usesoffsetbased pagination.@FilterableOffsetConnection- An@OffsetConnectionthat enables filtering the parent by fields of the connectionDTO.@CursorConnection- A connection that represents a collection (e.g, many-to-many, one-to-many) that usescursorbased pagination.@FilterableCursorConnection- A@CursorConnectionthat enables filtering the parent by fields of the connectionDTO.
Authorizers
In previous versions ofnestjs-query the resolvers relied on an AuthorizerService to be injected and the filters were created manually within the resolver.
In the latest version, we have transitioned to a interceptor/param decorator pattern. This provides:
- Better separation of concerns, auth filters are now just params passed to the resolver method.
- More flexibility when extending the resolvers to reuse the same logic that the auto-generated resolvers use without having to worry about internal implementation details.
- Easier extension of the
CRUDResolverby not having to worry about injecting the authorizerService, it will automatically add the interceptor and param decorators to auto generated methods, you just need to decorate your DTO. - Familiar patterns that are laid out in the core nestjs documentation.
Hook Updates
In previous versions of nestjs-query hooks were not very flexible, and could not be used by custom resolver endpoints. In the latest version the hooks pipeline has been re-worked to enable the following:- Hook decorators now accept either a hook funciton OR a custom hook class that can use dependency injection.
- Reusing hooks in custom endpoints.
- The
HookInterceptorin this example we reuse theBEFORE_UPDATE_MANYhook on theTodoItemDTO, the interceptor adds a DI hook instance to the context that can be used downstream by any guards or param decorators. @MutationHookArgswill apply the correct hook to the args and provide it to the resolver endpoint.
nestjs’s DI functionality you can inject other services to look up information and transform the incoming request as much as you need.
In this example we create a simple hook that will work for both createOne and createMany endpoints to set the createdBy attribute. In this example we look up the userEmail from the userService and set createdBy attribute on the input.
createdBy field
Registering DTOs When Using Custom Resolvers
In previous versions ofnestjs-query you could extend CRUDResolver but there was not a way to set up the appropriate providers for many of the newer features (hooks, authorizers etc.).
In the latest version you now have the option to register your DTOs with @ptc-org/nestjs-query-graphql without it generating a resolver automatically.
In this example we create a custom resolver that extends CRUDResolver.
todo-item.resolver.ts
TodoItemResolver extends CRUDResolver there is no need to have nestjs-query also create a resolver, instead you can specify the dtos option which just takes in DTOClass, CreateDTOClass, and UpdateDTOClass to set up all of additional providers to hooks, authorizers and other features.
todo-item.module.ts