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

Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

news.ycombinator.com

Post reply on HN
Print view View original

101–110 of 179 posts

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#101

Post by franky47 »

eropple wrote: post #97
franky47 wrote: post #88

Earlier quoted context omitted.

Ditto. It took me a while (coming from C++) to get that types are not the ideal source of truth in TypeScript, due to their disappearance at runtime. Having a runtime parser (which can consequently express things impossible with TypeScript types alone, like "a positive integer" rather than being satisfied with any instance of `number`) from which types are inferred, is a needed mindset shift made easy with Zod. I use…

Maybe I was unclear - my post was a criticism of Zod because it involves a bunch of duct tape that I'm not sure makes sense. Typebox just creates JSON Schema objects at runtime and projects them into the type system with `Static `. In so doing, you simultaneously create schema and types and the process of doing so is pleasant--you can just hand a TObject to Fastify as a validator object and you're done. Plus, with a…

Interesting, I'll have a look, thanks!

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#102

Post by seer »

I use it extensively in prod. Well the superset that is OpenApi. It enables contract first development where any change to the api is done in the schema fist, and then implemented by the clients/server.

Since we have tooling[0] that validates requests and responses at runtime, the clients can be absolutely sure of what they receive (we through 500 if the server attempts to respond with an undocumented respond) And the server is also sure about the shape of the requests. This allows us to validate everything at compile time too, generating typescript types for both client and server.

And since we have similar tooling regarding our data stores (typescript types for sql queries) most of the time if there is a bug, the code would simply not compile - pretty nifty!

[0] - https://github.com/ovotech/laminar

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#103

Post by peterkelly »

outworlder wrote: post #61
ysleepy wrote: post #7

Soon we'll have JSLT. JSON Query, JSON Pointer, JSON signatures etc are already there. And I say that as a conscious XML user. We are going in circles. At least XML has comments.

At this rate, we'll be back to S-expressions in 50 years or so.

Some of us never left :)

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#104

Post by pcthrowaway »

franky47 wrote: post #88
eropple wrote: post #45

Earlier quoted context omitted.

FWIW, I've had good success with Typebox over Zod for exactly this stuff. You don't need to compile out types, you just...have them.

Ditto. It took me a while (coming from C++) to get that types are not the ideal source of truth in TypeScript, due to their disappearance at runtime. Having a runtime parser (which can consequently express things impossible with TypeScript types alone, like "a positive integer" rather than being satisfied with any instance of `number`) from which types are inferred, is a needed mindset shift made easy with Zod. I use…

If you're going from Zod parsers to JSON schema, are you duplicating that in Typescript? Or can you just go ts-to-zod[1] then zod-to-json-schema?

[1]: https://github.com/fabien0102/ts-to-zod

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#105

Post by avmich »

lmm wrote: post #58
avmich wrote: post #55

Earlier quoted context omitted.

We seem to talk about different things. When doing deserialization, many wouldn't expect to add a custom code which would translate data and validate it - otherwise we would write the whole deserialization ourselves, I guess.

Most validation has to be done in custom code after deserialization (e.g. maybe a schema can enforce that the "collection ID" is in the right format, but it can't enforce that that collection actually exists in the datastore). There's definitely value in having a library/code generator/etc. to mechanically do the bytes -> structured value deserialization, but the cost/benefit of doing more complex validations at that…

For simple enough APIs it's possible to have all the validation in the form of JSON Scheme. Surely the id may be missing, but that could be not a "client error" - the input is syntactically valid, and for some APIs that's enough - but will cause the server to return the empty result set.

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#106

Post by dwaite »

smrtinsert wrote: post #40
lmm wrote: post #38

Earlier quoted context omitted.

The problem with XSLT wasn't that it was a fundamentally bad design, the problem was the horrible syntax. Well, and namespaces.

what was the problem? there's templates and queries and it seemed pretty clear once you read a quick intro.

Namespaces in XML was a bit of a bolt-on, and really showed the difference between the crowd who wanted to create XML to simplify defining new markup languages like HTML (the originators) and the XML as data crowd who wanted generalized tooling to support all XML data.

XPath really started to show the warts here - it leveraged namespaces as an axis, where your XPath could utilize namespaces which were defined at a particular element in the XSLT. However, this went against generalized tooling, as you had to understand which attributes or text were paths in order to know if namespaces had semantic value beyond the XML syntax itself.

IMHO, Canonical XML and XML Infosets were an effort to ret-con the new behavior back in - that namespaces and prefixes were not just used to serialize XML arbitrarily, but were semantically important parts of the XML itself. But at this point XML was too large to evolve - even XML 1.1 had relatively little market uptake.

On top of that, you had issues with how e.g. Microsoft Internet Explorer had divergent behavior for XSLT from other browsers/the spec.

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#107

Post by javcasas »

petilon wrote: post #11

Is this the right place to complain about lack of a native Date datatype in JSON? Also lack of inheritance support. (For example I want a way to specify that my json object should be deserialized as Dog not as Animal.)

JSON schema doesn't deal with how your language treats the underlying data - and shouldn't do it.

Use custom deserializers for that.

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#108

Post by franky47 »

pcthrowaway wrote: post #104
franky47 wrote: post #88

Earlier quoted context omitted.

Ditto. It took me a while (coming from C++) to get that types are not the ideal source of truth in TypeScript, due to their disappearance at runtime. Having a runtime parser (which can consequently express things impossible with TypeScript types alone, like "a positive integer" rather than being satisfied with any instance of `number`) from which types are inferred, is a needed mindset shift made easy with Zod. I use…

If you're going from Zod parsers to JSON schema, are you duplicating that in Typescript? Or can you just go ts-to-zod[1] then zod-to-json-schema? [1]: https://github.com/fabien0102/ts-to-zod

Zod schemas are the source of truth, from which TS types are inferred and JSON schemas are generated.

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#109

Post by schoetbi »

alfalfasprout wrote: post #5

Here's my gripe with jsonschema... In most cases where I want to do some validation on JSON I find that I usually have a class/struct/object that represents the payload and I want to unpack JSON into it (or dump that class to JSON). Ultimately, there are already nice tools to do this (eg; marshmallow on the python side). So unless I'm crossing language boundaries writing a separate jsonschema and using that is more w…

Flatbuffers can generate the json-schema for you out of the fbs files.

Re: Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees

#110

Post by benatkin »

AdieuToLogic wrote: post #51

> Do you use JSON Schema? At one point I did, but then discovered RAML[0] and it subsumed the value of what JSON Schema provides as well as being easier to work with than OpenAPI[1]. Also, generating JSON Schema from RAML definitions has proven to be a fairly straightforward process. The usual caveats apply... Your mileage may vary, my experiences do not speak for any others, my opinion does not detract from the valu…

I took a look at RAML and it also seems OK but not great like Swagger and JSON Schema. It isn't that I think I can come up with a better one, it's that I can see why such tools often aren't adopted and API docs are often published in non-machine-readable formats.

What I didn't like was that it doesn't infer something is an object and instead you have "type:object" repeated a lot. Also properties rather than props.

Post reply on HN