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

The Last Breaking Change

json-schema.org

Post reply on HN
Print view View original

21–30 of 66 posts

Re: The Last Breaking Change

#21

Post by 9dev »

mihaic wrote: post #9

Can anyone mention some interesting projects/use-case for JSON Schema? I have terrible WSDL flashbacks from a past project, where the abstraction layer was always either too high (something simpler was better) or too low (and written documentation was better).

We use Elasticsearch to store a vast amount of JSON documents in a specific format. Elasticsearch uses a strict schema to validate new items. Those documents are generated and used by several downstream projects. We have a single JSON schema installable as a package in all of our projects which is used in unit tests, and converted to the Elasticsearch schema format for reindexing. Effectively, this ensures we only have compatible documents in the index; all applications running in prod are verified to be able to handle them. Thus, we use JSON schema as an universally valid way to exchange the data schema.

Re: The Last Breaking Change

#22

Post by EdwardDiego »

andreareina wrote: post #20
EdwardDiego wrote: post #12

Earlier quoted context omitted.

Does OpenAPI support union types yet? More importantly, if it does, does Swagger support the OpenAPI version that does?

We have union types defined in fastapi/pydantic and they do show up in the api explorer. Tagged unions don't work but I think that's more to do with us/python than openapi.

Ah, that's nice. I think a year or so ago I was dealing with api docs that'd been run through Swagger and it just stopped emitting fields when it hit union types.

Re: The Last Breaking Change

#23

Post by singularity2001 »

smallstepforman wrote: post #11

For a format designed to be human readable, JSON not supporting comments is a major let down. And not supporting trailing comma.

Adding comments to json is the one breaking change the world needs. As a parser if you stumble over a comment it's your fault! nothing in the world could stop you from just sanely ignoring comments.

Re: The Last Breaking Change

#24

Post by grey-area »

smallstepforman wrote: post #11

For a format designed to be human readable, JSON not supporting comments is a major let down. And not supporting trailing comma.

What’s wrong with using a ‘comment’ key?

I’d say not supporting large ints is worse.

https://stackoverflow.com/questions/209869/what-is-the-accep...

Re: The Last Breaking Change

#25

Post by ttiurani »

mihaic wrote: post #9

Can anyone mention some interesting projects/use-case for JSON Schema? I have terrible WSDL flashbacks from a past project, where the abstraction layer was always either too high (something simpler was better) or too low (and written documentation was better).

A team of 10 devs I was a part of got lots of everyday value from JSON schemas (w/ code generation) being the single source of truth of the domain model for a Typescript frontend and Java backend.

I would absolutely choose JSON schemas again for any complex enough project that chooses typed languages for both backend and frontend. (And JSON as the protocol, naturally.)

Re: The Last Breaking Change

#26

Post by moring »

smallstepforman wrote: post #11

For a format designed to be human readable, JSON not supporting comments is a major let down. And not supporting trailing comma.

Counterpoint: In practically every language that supports comments, these "comments" are now used for language extensions (IDE folding markers, eslint-ignore, FPGA synthesis hints, ...)

Please don't do that to JSON.

Re: The Last Breaking Change

#27

Post by joeblubaugh »

This takes JSON schema from a fairly lightweight, flexible definition to one of the most rigid. As much as I have a hairs time with dynamic languages, I can’t get with this. Feels contrary to the spirit of the JS ecosystem in the first place.

Makes CUE a much more attractive way to directly validate JSON - you can declare with struct a are open or closed as part of the definition.

Re: The Last Breaking Change

#28

Post by _ZeD_ »

mihaic wrote: post #9

Can anyone mention some interesting projects/use-case for JSON Schema? I have terrible WSDL flashbacks from a past project, where the abstraction layer was always either too high (something simpler was better) or too low (and written documentation was better).

> Can anyone mention some interesting projects/use-case for JSON Schema?

finally come back to WSDL and SOAP.

sorry, you may have "terrible flashbacks", but I enjoyed those days, where I could have clients and server code auto generated, with automatic validation and so on, and I felt all these "unstructured" data sent over json as "dark ages".

I'm tired of writing again yet another rest client payload mapping by hand...

Re: The Last Breaking Change

#29

Post by noctune »

grey-area wrote: post #24
smallstepforman wrote: post #11

For a format designed to be human readable, JSON not supporting comments is a major let down. And not supporting trailing comma.

What’s wrong with using a ‘comment’ key? I’d say not supporting large ints is worse. https://stackoverflow.com/questions/209869/what-is-the-accep...

JSON supports numbers of arbitrary and just fine. It's just many reader/writers of JSON does not, and those are so ubiquitous that it's often not practical to use.

Re: The Last Breaking Change

#30

Post by wolpoli »

_ZeD_ wrote: post #28
mihaic wrote: post #9

Can anyone mention some interesting projects/use-case for JSON Schema? I have terrible WSDL flashbacks from a past project, where the abstraction layer was always either too high (something simpler was better) or too low (and written documentation was better).

> Can anyone mention some interesting projects/use-case for JSON Schema? finally come back to WSDL and SOAP. sorry, you may have "terrible flashbacks", but I enjoyed those days, where I could have clients and server code auto generated, with automatic validation and so on, and I felt all these "unstructured" data sent over json as "dark ages". I'm tired of writing again yet another rest client payload mapping by hand…

I agree, WSDL were great. There was no need to keep checking the API doc because the client codes were auto-generated.

If we can't have JSON Schema, perhaps we could have a large language model auto generate our client codes by ingesting the API doc.

Post reply on HN