graphql-binding

GraphQL binding reference

@kavo/graphql (packages/protocols/graphql) builds a GraphQLSchema over an existing createCrud service. Every resolver calls directly into the same DefaultKavoService/engine pipeline REST binds to — no parallel request path, no second copy of filter/sort/pagination validation, no separate error handling. Full detail: docs/internals/architecture/13-graphql-binding.md (and ADR-0016 for the package-boundary rationale).

@kavo/graphql is host-framework-agnostic: it imports @kavo/core and the graphql peer only, never @kavo/nest. @kavo/nest depends on @kavo/graphql, not the other way around.

One entity

import { createKavoGraphQLSchema } from "@kavo/graphql";

const schema = createKavoGraphQLSchema({
  name: "Owner",
  service: ownerService, // whatever createCrud(Owner, ...) returned
  itemType: OwnerType, // hand-written GraphQLObjectType
  createInputType: CreateOwnerInput, // optional — omit to skip the mutation
  updateInputType: UpdateOwnerInput,
  patchInputType: PatchOwnerInput,
  deleteOne: true,
  restoreOne: true, // meaningful only if Owner declared soft delete
  purgeOne: true,
});

These flags do not cross-check REST's @Kavo config. Setting restoreOne: true here for an entity whose @Kavo config disables restoreOne still adds the field to the schema — it throws OperationDisabledException at resolve time instead, same as calling the REST route would. Keeping the two declarations in sync is your job today.