Testing in production: using JSON Schema for 3rd party API response validation • Hacker News Board

Re: Testing in production: using JSON Schema for 3rd party API response validation

#21

Post by beached_whale » Sun, Aug 08, 2021, 3:45 PM UTC

mrloba wrote: post #2

I like this approach a lot. I wonder if it's a good idea to keep the assertions in prod as well. I guess this is a trade-off between safety and convenience.. As a side note, what do people think about JSON schema? I find it quite verbose and cumbersome (compared to, say, typescript type definitions)

It seems fine for validation, but when I want an IDL it seems to be vague in describing the indended data structure. This is in terms of cross platform dev and far from JS. It’s fine for describing the string like things, but when getting into sum types it doesn’t give more than `dependencies` to describe a tag descriminator. Going the other way, that doesn’t say more than both need to be there when the sum type is present.

Re: Testing in production: using JSON Schema for 3rd party API response validation

#22

Post by Zababa » Sun, Aug 08, 2021, 5:25 PM UTC

It's a bit of a shallow analysis but I lack experience about this so excuse me in advence. I see more and more people importing a lot of libraries to write Typescript code. Part of it is libaries to do things (like in the article), part of it is libraries to change the language (like fp-ts). In my (limited) experience I saw the same thing with Scala, with people using cats or equivalents. I wonder, does this happen in other languages to? Does it lead to ecosystem splitting? Is this the sign of a language becoming "enterprise" or "mature"?

Re: Testing in production: using JSON Schema for 3rd party API response validation

#23

Post by pbronez » Sun, Aug 08, 2021, 5:32 PM UTC

alexdean wrote: post #13

Back in the early years of Snowplow, we adopted a similar approach for our support of 3rd party webhooks[1] as an event stream source supported natively by Snowplow ( https://github.com/snowplow/snowplow ). (The important background here is that all events and entities flowing through Snowplow are described using versioned JSON Schema). We built a kind of Maven Central for 3rd party webhooks' schemas[2], and got to w…

Seems like this is a feature you could demand if you were a big enough client of their enterprise products. Better yet, get a critical mass of big clients together and push for it. You could probably do this by showing up at a product-specific conference and networking with the other devs who care enough about the tool to show up.

Also, if this is a genuinely useful thing to have, you could probably monetize it directly. Decouple the schema repository from your primary application and sell access to well-validated, performant client libraries for popular SaaS APIs.

Re: Testing in production: using JSON Schema for 3rd party API response validation

#24

Post by samhh » Sun, Aug 08, 2021, 5:35 PM UTC

Zababa wrote: post #22

It's a bit of a shallow analysis but I lack experience about this so excuse me in advence. I see more and more people importing a lot of libraries to write Typescript code. Part of it is libaries to do things (like in the article), part of it is libraries to change the language (like fp-ts). In my (limited) experience I saw the same thing with Scala, with people using cats or equivalents. I wonder, does this happen i…

I think fp-ts exists because TypeScript is entrenched with a strong job market. If that weren't the case most users would just use something like PureScript.