Design Scope

json-rest-schema is intentionally synchronous. Shared schemas need to run the same way on the client and the server, so this library is scoped to:

• typing and casting
• normalization
• local field validation
• local cross-field validation

It is not the place for database-backed uniqueness checks, external API lookups, or any other stateful async business rule. Put those checks in higher layers such as services, repositories, or actions after schema validation has produced a normalized payload.

json-rest-schema is also deliberately scoped to runtime validation and transformation. It does not prescribe a specific persistence layer. Treat the schemas you build with this library as the canonical description of your data when you design storage models, migrations, API responses, or documentation.

If you pair the library with a database toolkit (such as Knex), keep the tooling concerns separate: write migrations and models in the tool that best fits your project, then reuse the same field definitions inside createSchema so validation, casting, and persistence stay aligned.

Looking for automation around database schema generation? See FUTURE_MIGRATION_MODULE.md for a high-level proposal of an optional companion package.