Live data from Hacker News

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

news.ycombinator.com

141–150 of 179 posts

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

#141
post #36

JSON Schema is awesome. I wish Typescript had better support for it though, having to do stuff in Zod and JSON Scheme sucks. I have a system I built that compiles TS types to JSON schema, which then validates data coming into my endpoints, this way I am typesafe at compile time (Typescript API) but if someone hits my REST endpoint w/o using my library, I still get runtime goodness. The number of different ways that J…

Maybe a better solution (not necessarily for your exact your use case) would be to generate the Typescript types from JSON schema? The schema feels more like it should be the real source of truth. That's how protobuf (for example) works - there's a language-independent schema and you can generate types for any languages you wish (but don't have to depend on any particular language if you don't need it).

This is pretty doable with mapped types in TS, to make it work without a compilation step though is pending on https://github.com/microsoft/TypeScript/issues/32063

Although in practice the mapped types to do this do slow down the typing service non trivially.

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

#142

I'm not currently using it, but I'm strongly considering validating json in postgres with https://github.com/supabase/pg_jsonschema - which uses the https://docs.rs/jsonschema/latest/jsonschema/ Rust crate So I'm not sure if my feedback is valid but, I sure hope that the jsonschema crate follows the spec! Otherwise I'll never use jsonschema but instead something-not-exactly-jsonschema. In other words.. you better not…

the jsonschema crate is spec compliant and has full implementations for the required parts of drafts 4,6, and 7

pg_jsonschema matches that support with the caveat that it doesn't support loading documents over http since that would be risky behavior inside a database

disclaimer: I'm the author of the pg_jsonschema

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

#143
post #102

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 th…

How do you keep the openapi spec file updated over time ? Our problem is usually making sure changes to the api get reflected and updated in the open api spec file.

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

#144

I haven't used JSON Schema (knowingly, at least) in my professional software career. I wonder why that is. There are things that seem to supersede it, namely type systems. GraphQL types with compiled clients wouldn't have a need for this (I don't think?). Neither would Golang generated clients from GraphQL specs, nor gRPC/protobufs. JSON storage / data passing within applications is covered by Typescript. For librari…

I had a similar experience evaluating the state of the ecosystem and finding it not ideal. The schema format is great and schemas are great ways to validate your input / make your programs easier to reason about — but with the state of the ecosystem, it’s hard to actually make use of that validation in any but the most trivial ways. The problem with using it directly was that the validators did not produce very usabl…

Postscript — a surprise good part of schemas was validating all the data our code produced before sending it out. The code would return 500 rather than going out of spec. It made things easier to find and fix.

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

#145
I built a tool which uses JSONschema for validating custom policy documents as part of a GitHub Action pipeline. The documents get processed for updating HashiCorp Vault, and being able to validate/restrict fields like "email address domain" keeps InfoSec happy.

Part of my motivation to build the tool was to learn more about JSONschema.

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

#146
post #18

Earlier quoted context omitted.

This one is good - https://json-schema.org/understanding-json-schema/index.html . I also found this site useful - https://cswr.github.io/JsonSchema/spec/grammar/ .

Watch out for that second link. Not everything there is accurate. If you or anyone has suggestions to improve the docs (first link), filing issues or PRs are more than welcome!

> Watch out for that second link. Not everything there is accurate.

Can you elaborate please? I particularly like their well formedness concept.

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

#147
post #135
post #105

Earlier quoted context omitted.

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.

You can't accept a write if you're going to break a foreign key constraint when you insert the row. And I struggle to imagine a case where you want to do complex validation like "multiple of x" or "matches this regex" but don't want to actually check if the thing exists.

I used matching regexes to check if a particular string actually has a time moment, in the form YYYY-MM-DD hh:mm:ss.xxx .

If you add events, they may not have FKs, you just add them to the table while generating PKs on the fly. This is useful in many cases. There could be other approaches with different cases, I suspect.

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

#148
post #57

This gives you a pretty good feel for where it’s at: https://json-schema.org/blog/posts/future-of-json-schema I’m invested in it. I’m using it to provide implementation-specific validation of requests to/from a third party API. I wish there was a good macOS editor or IDEA plugin for it with autocomplete etc. The static generators from examples are obscure, ugly, minimal, and can’t account for variations. It isn’t ple…

The one out of the box with IntelliJ is pretty decent for checking YAMLs with JSON Schemas, is there something you're missing?

Yeah, I'm writing the schema by hand to describe someone else's API by cross-referencing their API docs and the actual (integration-specific) requests/responses. So there's nothing automatic in my case beyond the native JSON support. Storm doesn't offer autocomplete based on the JSONSchema spec.

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

#149
post #36

JSON Schema is awesome. I wish Typescript had better support for it though, having to do stuff in Zod and JSON Scheme sucks. I have a system I built that compiles TS types to JSON schema, which then validates data coming into my endpoints, this way I am typesafe at compile time (Typescript API) but if someone hits my REST endpoint w/o using my library, I still get runtime goodness. The number of different ways that J…

I had something like this and turned into a library: https://www.npmjs.com/package/rototill

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

#150

Earlier quoted context omitted.

Decimal types don't exist in JSON. If you need decimals, you definitely should encode them as strings. As JSONschema exists to document JSON, it should be agnostic to that. You can if you wish, provide format information in the format field, which is not prescriptive.

Neither binary nor decimal floating point types exist in the JSON spec. The JSON spec does not give an explicit internal representation for floating points, implementations are free to use decimal types internally, if they wish to do so. The JSON spec merely specifies what a "number" is at the grammar level. Having said that most implementations don't use decimal floating points to represent these.

That is correct, but JSONschema does and there is an implicit behavioural difference introduced by the existence of the MultipleOf filter when you're dealing with floats versus integers that can't simply be elided away or excused by the lack of a distinction in the underlying type system.

The point is JSONschema could take a stand and say for example, "this filter will always fail when the operand is not the number representation of an exact integer".

Post reply on HN