How porting to TypeScript solved our API woes

Re:How porting to TypeScript solved our API woes by a_humean on Wednesday April 08, 2020 @06:03PM (#22817688)

It is actually quite frustrating compared to some other languages, and more often than not you see that its just `JSON.parse` and hope for the best. I wish we had something like Rust's Serde or Haskell's aeson.

If you want to validate data coming over IO then your options are data validation libraries such joi, io-ts, and yup. You have to write seperate data validators on top of your types. io-ts has a way of deriving types from validators, but io-ts is often seen as quite intimidating being built on top of fp-ts.

No matter how carefully you maintain strict typing within your typscript project the moment you hit IO everything is basically `any`.

Some projects like openapi-generator might generate some validators for server respones, but I've not seen any good generators that do actual validation.

I'm not sure if apollo-graphql does responses validation? Does anyone know?

[ Parent | on HN ]

Re:How porting to TypeScript solved our API woes by willberman on Wednesday April 08, 2020 @06:54PM (#22818081)

I second the use of iots. It has a decent learning curve but is very worth it in the end.

[ Parent | on HN ]

Re:How porting to TypeScript solved our API woes by eropple on Wednesday April 08, 2020 @07:50PM (#22818434)

Plenty of web frameworks can validate via JSON Schema, using ajv under the hood. (I use Fastify.)

io-ts is pretty scary, though. I like the `runtypes` library but it doesn't help me express my types in a way clients can consume, which, enh.

[ Parent | on HN ]

Re:How porting to TypeScript solved our API woes by Kinrany on Saturday April 11, 2020 @11:08AM (#22842035)

I also liked runtypes more, but it turns out composing io-ts codecs is perfectly readable, and being able to deserialize at the same time/instead of validating is very convenient.

Caveat, I've only been using it for two weeks.

[ Parent | on HN ]

Re:How porting to TypeScript solved our API woes by seer on Thursday April 09, 2020 @01:07AM (#22819945)

Apollo does indeed validate responses as well as requests. If your server tries to send an object that doesn’t match the schema, you’re going to return just a 500 error, which means your clients can trust the graphql types implicitly.

Since in my current job I can’t use graphql but have to type everything in openapi, Had to resort to writing my own lib to get to the same functionality for a REST backend in TS - https://github.com/ovotech/laminar

[ Parent | on HN ]

Re:How porting to TypeScript solved our API woes by Ezku on Wednesday April 08, 2020 @11:48PM (#22819592)

My personal take is that io-ts _is_ typescript’s aeson, but if you’re scared of the baggage it comes with then how about giving zod a try? https://github.com/vriad/zod

[ Parent | on HN ]