A GraphQL directive for validating input fields with constraints like minLength, format, and pattern.
graphql-constraint-directive is a GraphQL directive library that adds validation capabilities to GraphQL schemas. It allows developers to define constraints like minimum length, format, and numeric ranges directly on input fields using the `@constraint` directive, ensuring data integrity at the schema level without extra validation code.
GraphQL API developers using Node.js frameworks like Apollo Server, GraphQL Yoga, or Express who need declarative input validation in their schemas.
It provides a standardized, schema-first approach to validation that integrates seamlessly with popular GraphQL servers, reduces boilerplate, and keeps validation rules co-located with type definitions for better maintainability.
Validate GraphQL fields
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Supports a comprehensive set of validations including string formats (email, UUID), numeric ranges, array sizes, and custom regex patterns, as detailed in the API section.
Offers multiple adoption paths: schema wrapper, Envelop plugin, and Apollo Server plugins for various GraphQL setups, allowing teams to choose based on their server environment.
Enables user-friendly error feedback via the errorMessage argument, making it easier to provide clear validation failures to clients.
Automatically appends constraint descriptions to field documentation using constraintDirectiveDocumentation, enhancing schema introspection without manual updates.
The schema wrapper implementation replaces basic GraphQL scalars (Int, Float, String) with custom scalars, which can break compatibility with tools or libraries expecting standard types.
Server plugin integrations only validate input query variables and not response data, restricting validation to mutations and queries with variables, as noted in the caveats.
Requires different setup procedures for Apollo 3, Apollo 4, Envelop, etc., with specific dependencies (e.g., @apollo/server for Apollo 4), increasing initial configuration overhead.