Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Designing the perfect TypeScript schema validation library

vriad.com

Post reply on HN
Print view View original

61–70 of 77 posts

Re: Designing the perfect TypeScript schema validation library

#61

Post by pas »

donatj wrote: post #59

Call me old fashioned, but "mission-critical" and "rock-solid" are inherently at odds with anything that runs a on a clients machine. Doubly so for something that runs in an interpreted language, especially one that doesn't ship with it's own interpreter to said client. In these cases I'd far rather see an old fashioned reliable server-side application built in a language with a lot of built in safety. The less you a…

Engineering has to consider cost too. Haskell might be amazing at this, but that might cost a lot more. TS sounds like a complicated beast, and of course has a lot of security trade offs (npm, myriad of unverified/unaudited packages), but using TS on both the client and the server makes things simpler, can cut down costs, help with time to market, yadda-yadda.

Sure, TS has other problems too. (Soundess issues in its type system.) But still much safer than C/C++ in many aspects.

Java might be an old fashioned server-side thing. But again, it has a rather old ecosystem and it's not exactly know for its high quality and security consciousness.

Contrast that with Rust, which is young, but tries to (or had already?) establish itself as the de-facto ecosystem for critical/safety/performance things.

TS is basically that. Rust for the masses. For anyone who picked up JS and found themselves at end of a bootcamp, or anyone who wants to step beyond being a webdev. So compared to vanila JS (and pure C, and pure python, and maybe even pure Java) TS stuff is rock solid. (Thanks to browser vendors spending a lot on browser/DOM/JS-engine security.)

Furthermore. Security _must_ consider ergonomics. Otherwise it will be bypassed. (Eg it simply won't spread, users will work around the secure way, etc.) So if you can simply use the same validation things on your client to provide early in-situ feedback about what's wrong with the input, you can build more robust user interaction flows, which help with people using your secure product.

Re: Designing the perfect TypeScript schema validation library

#62

Post by pas »

hn_throwaway_99 wrote: post #43

While I think this is pretty cool, given his use case (wanting to use a strongly typed client and server), I can't see why one wouldn't just use GraphQL with TypeScript on both the client and server. I've done this and I love it: 1. Define the GraphQL interface with GraphQL's typedef language. GraphQL then takes care of validating all the request and responses at runtime. 2. Use something like https://github.com/dota…

One use case of validators is for config files.

Re: Designing the perfect TypeScript schema validation library

#63

Post by Gehinnn »

nateabele wrote: post #60

Also did something similar[1]. My motivations were a better API (mine is modeled off of Elm's), and better error messages: I have a use case where user's need to be shown raw, dev-tools-style interactive data dumps, with error information overlaid on top. The next version will also enable data generation from schemas. Also, and perhaps most importantly, this library has no respect for undefined, because particularly…

I find `undefined` better than `null`. Either a user has contact information, or the contact information are undefined (and not null). How do you model that?

Re: Designing the perfect TypeScript schema validation library

#64

Post by AriaMinaei »

I've used a few similar libraries [0][1][2] and wrote one for a personal project. If we categorize them as embedded DSLs for runtime type checking with some support for static interop, they all share three major flaws:

1. Sub-optimal developer experience: significantly noisier syntax compared to pure typescript, convoluted typescript errors, and slower type checking.

2. Unfixable edge cases in static type checking: Features like conditional types work less reliably on the types produced by the library.

3. Some typescript features can't be supported in the library (again, conditional types).

I think a better way to approach the runtime+static type checking is to do it as a babel plugin, which would fix the DX and edge-case problems and also gracefully degrade in the case of typescript features that can't work in runtime.

Since babel can now parse typescript, it is trivial to write a babel plugin that takes regular typescript files and converts their type annotations into runtime values [4]. Those values can then be fed into a simpler type checking library, giving us runtime type checking on top of the native static type checking experience.

[0] https://github.com/gcanti/io-ts

[1] https://github.com/pelotom/runtypes

[2] mobx-state-tree also has a schema validation library that works to some extent statically: https://github.com/mobxjs/mobx-state-tree/

[3] https://github.com/gcanti/io-ts#branded-types--refinements

[4] https://gist.github.com/AriaMinaei/2f1229178abad4363f5180db2...

Re: Designing the perfect TypeScript schema validation library

#65

Post by eyelidlessness »

seanwilson wrote: post #57

Are there any plans for building validation support like this directly into TypeScript? If not, why not? TypeScript seems designed to be incrementally added to large existing projects. Why then isn't there a standard way to validate objects coming from the untyped parts of your project?

It's explicitly one of their non-goals[1]:

> Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

This approach (build runtime behavior that produces static types) is the intended one.

[1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

Re: Designing the perfect TypeScript schema validation library

#66

Post by nateabele »

Gehinnn wrote: post #63
nateabele wrote: post #60

Also did something similar[1]. My motivations were a better API (mine is modeled off of Elm's), and better error messages: I have a use case where user's need to be shown raw, dev-tools-style interactive data dumps, with error information overlaid on top. The next version will also enable data generation from schemas. Also, and perhaps most importantly, this library has no respect for undefined, because particularly…

I find `undefined` better than `null`. Either a user has contact information, or the contact information are undefined (and not null). How do you model that?

See, I take the opposite view: consider that the 'model' is the abstract structure of the data which your application knows about.

In your case, contact info is a piece of related data that your application knows about, can traverse to, parse, and consume, and it can be either present or absent. To me, `null` fits that case perfectly (personally I'd use Maybe, but, same idea). Finally, in cases where you're modeling a collection of values where the keys are unknown, see `dict()`.

Re: Designing the perfect TypeScript schema validation library

#67

Post by eyelidlessness »

pas wrote: post #62
hn_throwaway_99 wrote: post #43

While I think this is pretty cool, given his use case (wanting to use a strongly typed client and server), I can't see why one wouldn't just use GraphQL with TypeScript on both the client and server. I've done this and I love it: 1. Define the GraphQL interface with GraphQL's typedef language. GraphQL then takes care of validating all the request and responses at runtime. 2. Use something like https://github.com/dota…

One use case of validators is for config files.

FWIW, you can somewhat accomplish this with just the `config` library and config files written as TypeScript.

Re: Designing the perfect TypeScript schema validation library

#68

Post by Gehinnn »

nateabele wrote: post #66
Gehinnn wrote: post #63

Earlier quoted context omitted.

I find `undefined` better than `null`. Either a user has contact information, or the contact information are undefined (and not null). How do you model that?

See, I take the opposite view: consider that the 'model' is the abstract structure of the data which your application knows about. In your case, contact info is a piece of related data that your application knows about, can traverse to, parse, and consume, and it can be either present or absent. To me, `null` fits that case perfectly (personally I'd use Maybe, but, same idea). Finally, in cases where you're modeling…

What is `dict()`? What's the meaning of `null`? `undefined` literally means the value is not defined. `null` only has a technical meaning, which says its value is the null pointer.

Re: Designing the perfect TypeScript schema validation library

#69

Post by pas »

eyelidlessness wrote: post #67
pas wrote: post #62

Earlier quoted context omitted.

One use case of validators is for config files.

FWIW, you can somewhat accomplish this with just the `config` library and config files written as TypeScript.

Sure, this discussion is full of options, but none are really perfect, so there are plenty of opportunities for bikeshedding!

Re: Designing the perfect TypeScript schema validation library

#70

Post by eyelidlessness »

pas wrote: post #69
eyelidlessness wrote: post #67

Earlier quoted context omitted.

FWIW, you can somewhat accomplish this with just the `config` library and config files written as TypeScript.

Sure, this discussion is full of options, but none are really perfect, so there are plenty of opportunities for bikeshedding!

I guess you could call trying to offer a helpful suggestion bike shedding ¯\_(ツ)_/¯
Post reply on HN