News for hackers. Stuff that matters.
Re:How porting to TypeScript solved our API woes by cameronfraser on Wednesday April 08, 2020 @05:17PM (#22817259)
How does one deal with remote data in typescript? I really like typescript, but not having any guarantees on the returned data is kind of frustrating.
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?

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.
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.

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.

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

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
Re:How porting to TypeScript solved our API woes by andy_ppp on Wednesday April 08, 2020 @05:18PM (#22817272)
There are things like io-ts that do exactly this: http://github.com/gcanti/io-ts
Re:How porting to TypeScript solved our API woes by moltar on Wednesday April 08, 2020 @08:20PM (#22818613)
Yup plus see other projects in the same vein:

https://github.com/moltar/typescript-runtime-type-benchmarks

Re:How porting to TypeScript solved our API woes by latchkey on Wednesday April 08, 2020 @07:36PM (#22818352)
For my current project, it is handled by GraphQL. Using a combination of type-graphql and code generation, I have fully round trip static types on both client and server, by only defining my model once. Even my graphql queries are checked.

It is a bit of a pain to setup, but once it is done, I've found that it works pretty well.

[1] https://github.com/MichalLytek/type-graphql/

[2] https://graphql-code-generator.com/

Re:How porting to TypeScript solved our API woes by 0XAFFE on Thursday April 09, 2020 @06:21AM (#22821193)
I use a combination of class-transformer[1] and then class-validator[2].

First transform the JSON into proper class-objects and then validate the object for correctnes.

IMHO this has nothing to do with TypeScript because in your runtime all the type information is gone and you need to validate the remote data never the less. TypeScript can help you structure your validations but you need to write them.

[1] https://github.com/typestack/class-transformer

[2] https://github.com/typestack/class-validator

Re:How porting to TypeScript solved our API woes by Geeflow on Thursday April 09, 2020 @02:05AM (#22820203)
I use tcomb-validation[1] to validate incoming data. The downside is that it cannot use TypeScript types so you have to define the schema twice.

For me, the duplicated types turned out to be less of a hassle than initially anticipated. In many cases, I ended up with different data structures anyway because the data is transformed in the client. I think of them as transport types and client types.

[1]: https://github.com/gcanti/tcomb-validation

Re:How porting to TypeScript solved our API woes by postalrat on Wednesday April 08, 2020 @05:33PM (#22817408)
Let it fail and make sure you are getting notified.
Re:How porting to TypeScript solved our API woes by JoshuaScript on Wednesday April 08, 2020 @07:26PM (#22818290)
https://quicktype.io/ is a nice solution
Re:How porting to TypeScript solved our API woes by k__ on Wednesday April 08, 2020 @05:25PM (#22817330)
AWS Amplify has a code generator that uses GraphQL to generate client side TypeScript and server side APIs
Re:How porting to TypeScript solved our API woes by k__ on Wednesday April 08, 2020 @09:13PM (#22818919)
Just found out they're using this:

https://graphql-code-generator.com/