class-validator VS Graphweaver

You can learn more from the documentation here.

This is the request body when creating a new task. The IsString decorator provided by class-validator rejects all types other than strings, including undefined or null. The task name value object does not consider the possibility of values other than strings.

In this class, we are using the famous class-validator to decorate our request parameters. This way it is more clear how we are going to use our request object and everything.

We add validation using https://github.com/typestack/class-validator.

I will make sure we get this documented.

Also OP can check out class-transformer + class-validator if he want to properly instantiate objects and validate them with precise and verbose output of potential format errors. OP can even go the god tier way by setting up a custom RxJS operator that does that for him easily.

Start by installing the class-transformer and class-validator packages for dto validation (see more in the docs), sharp for image optimization, and the S3 client packages.

The description of the request body model in NestJS is similar to the description of Ditsmod models, but NestJS uses decorators provided by the utility class-validator. In NestJS, it is customary to name the request body model with the ending *Dto (this is an abbreviation of Data transfer object):

You could use Zod or Superstruct to validate the types of values, or use typestack/class-validator if it makes sense.

Also, title of before article was I made 1,000x faster TypeScript validator library, but today's benchmark is showing that typescript-json is maximum 6,500x times faster. It's just because I added a new library class-validator in the benchmark and it is much slower than previous zod. Of course, I've continuously tuned the performance, but it just improved the performance about 2x times only.

You're right we need to improve the documentation on this. We do have an example though:

https://github.com/exogee-technology/graphweaver/tree/main/s...

We have also added the OpenAPI spec on the roadmap however, every REST API we have integrated so far has been custom.

The REST connector allows you to have full-control over how it connects to the API:

https://github.com/exogee-technology/graphweaver/blob/main/s...

We’re a small dev team based in Sydney and in between client projects we’ve been working on our own open-source tool, Graphweaver. Graphweaver allows you to combine multiple data sources (Databases, Rest APIs, Saas platforms) and expose a single GraphQL API. It’s a bit like Hasura or Step Zen but with more of a code-first flexibility. It can take your database and with a single import command, generate your code and create a backend.

GitHub Repo: Graphweaver

Turn multiple data sources into a single GraphQL API Graphweaver is a GraphQL Gateway that can connect many data sources together to create an API. It can be used to create a headless CMS, an API Gateway, or used as a Backend for mobile apps.

GraphQL is the leading method of querying APIs in modern web development. Yet, developers face a common challenge using GraphQL: managing the types and structures of the data returned by their queries. Dealing with undefined values and casting partial types to make the Typescript compiler happy is frustrating. Or constructing types for each kind of response. But, there's a solution that alleviates this pain, boosts development speed, and enhances code quality – GraphQL Codegen. This powerful open-source tool automates the generation of code for GraphQL APIs. GraphQL Codegen produces types, queries, and hooks from the GraphQL schema. No more manual repetitive coding or uncertainty about types. In this post, we'll explore how GraphQL Codegen works, and how we use it in our open-source tool Graphweaver to facilitate a silky smooth developer experience. So let's dive in and uncover how this tool is reshaping the way we build applications.

Graphweaver Repo: https://github.com/exogee-technology/graphweaver