Typescript & simpl-schema - Making the move to TS and having basic questions

[radekmie]

I think I have an entirely different approach, so let me share it as well.

@ivo

1/ Is it useful to have both TS and simpl-schema ? it feels like they are partly redundant but simpl-schema has the validate method to ensure checking before inserting/updating data.

No, it’s not redundant at all. As @rjdavid said, TypeScripts is for the programmer to prevent runtime errors (here: invalid data) from happening. Then the SimpleSchema is actually checking the data.

However, you don’t have to use SimpleSchema to do that. Even the Meteor-native check function may be enough in some cases, at least as the amount of validation you perform is relatively small. (It also lacks a proper error reporting and that may be needed, especially for the end-users.) If you’ll use @types/meteor, check becomes a handy type guard (source):

Meteor.methods({
  example(input: unknown) {
    // input: unknown
    check(input, {
      x: Match.Optional(Number),
      y: Number,
    });
    // input: { x?: number; y: number }
  },
});

I do use it quite extensively, especially when the input is sort of “internal”, i.e., I don’t care about the error message.

@captainn

There are definitely benefits to having these two in sync. I typically use a mix of technology to make this happen. Most recently I’ve been using GraphQL and Apollo to get those benefit, and sort of leaving Simpl-Schema/Collection2 behind for a bunch of reasons.

I do agree, it’s awesome to have them in sync. But it’s also tedious. Some time ago I’ve experimented with automatic type inference for SimpleSchema (TypeScript 4.3 and SimpleSchema), but I didn’t use it in the end. And that’s not because it won’t work, but because I’m trying not to use SimpleSchema at all.

When it comes to GraphQL, I most often go with the schema-first approach, use GraphQL Codegen to create TypeScript types, and then implement the already typed resolvers. (Just keep in mind, that the validation in GraphQL is very limited: no “minimum length”, “maximum value”, etc. You have to do it with custom in-DSL directives or directly in the resolvers.)

@captainn

In another pure Meteor app, I used some really cool JSON Schema → typescript tools, with some runtime validation in methods running through ajv (validators generated from JSON Schema). I never set it up, but you can use the same JSON Schema in the Mongo tier, for additional type safety. Since the ajv validators were run in mdg:validated-method I had full stack runtime data validation which was in sync with my static type validation through typescript. All my validators and types were generated at once with a script. Wonderful.

That’s a great one, really! There are so many great tools to work with JSON schema (including uniforms), that it’s not only easier to work with but also definitely more future-proof. If it matters for you, you can also share the schema with 3rd parties, like external integrators.

What is more, you can use the same JSON schema both in-app (for validation) and directly in-MongoDB (for ensuring data consistency). Of course, the latter is something that should never be needed, but it’s good to have it. Check out Using built-in MongoDB schemas for more.

@captainn

I’ve even gone in the other direction - take a typescript/flow document provided by an API vendor, generate JSON Schema from that, then generate a validator, to make sure I validate my API inputs (always validate your inputs! even from APIs).

That’s one of the advantages of cross-technology standards. I can also recommend doing the opposite, i.e., write code that generates both the types as well as the schema (and then use the schema to create a validator, using ajv). One tool I strongly recommend is typebox.

@captainn

None of that was possible with Simpl-Schema and collection2 - or at least, it wasn’t as easy (I still don’t know how to make types out of it, seems cumbersome). And this is not to disparage Simpl-Schema. I’ve used it for years, and it’s served my needs very well. I appreciate all the work that went in to it all. For me, it was just time to move on.

I also have used it for years. And probably will for a couple more, in some projects. But personally, I do switch to JSON schema whenever possible. Same goes for aldeed:collection2 and universe:collection - I try not to have any sort of ORM/ODM at all and handle the raw (helper-less) objects instead.