
Show HN: JSONSchema to TypeScript compiler - bcherny
https://github.com/bcherny/json-schema-to-typescript
======
YousefED
Very cool. Imo one of the big benefits of Typescript is the possibility to
better tool interoperability.

In case you need to do the reverse, for example model-first in typescript and
want to generate JSONSchema:

Typescript Code to JSONSchema: [https://github.com/YousefED/typescript-json-
schema](https://github.com/YousefED/typescript-json-schema) \- started this
long ago but some great contributors are leading it since!

~~~
bcherny
Awesome work. Expressing concepts that TS's type system can't handle (eg.
minimum) as comments is an approach that I didn't consider. So far I've been
focused on the idea of generating decorators [0], but comments seem like a
solid stopgap. Especially because they show up as tooltips in VSCode.

[0] [https://github.com/bcherny/json-schema-to-
typescript/issues/...](https://github.com/bcherny/json-schema-to-
typescript/issues/8)

------
lolive
Just a question. How does JSON and JSONSchema deal with graph structure? For
example, what happens when your data structure in memory is A->B->C->A. And
you want to serialize/deserialize such a data structure. (as far as i
undestand, the JSON serialization of this graph would have duplicated A, once
a top level and once inside the serialization of C).

~~~
akst
You can probably encode a directed graph by storing the nodes as values in a
dictionary which track which nodes they point too, and the keys of the
dictionary would be the node identifiers. If you represent it a specific way
in your program, just perform a normalisation phase after decoding, and vice
versa for encoding.

~~~
lolive
As far as I understand, this is the way RDF works. I use N3.js and it
basically does that. Is it a need that usually appears when you send JSON
between server and client?

~~~
akst
Not sure what the requirements are for the parent comment, I'm just explaining
an approach to serialise a graph data structure.

------
skrebbel
Yes! Fantastic. Typescript interfaces are a great way to specify JSON schemas,
much friendlier than eg JSON Schema and the likes.

Now that TypeScript is gaining traction it might be a great moment to start
documenting your REST payloads with it instead of eg JSON Schema or just some
JSON example blobs. It's very readable even for non TypeScript programmers.

~~~
elcapitan
You can use OpenAPI/swagger to do that, which contains a subset of Json
Schema, you have the option to use Yaml instead of json notation and have it
language-independent and with the option to generate client and server code
for multiple languages.

------
burntcaramel
I’ve made something quite similar, with a friendly hashtag syntax, that live
updates into React PropTypes, Mongoose, Swift, Elm, Golang and more —
[https://schema.lofi.design/](https://schema.lofi.design/)

Planning on adding TypeScript soon, and may do JSONSchema too!

It’s written in Elm, whose strict compiler really helps with avoiding bugs.
[https://github.com/RoyalIcing/lofi-schema-
elm](https://github.com/RoyalIcing/lofi-schema-elm)

~~~
fixed_carbon
Nice. Being able to consume JSON Schema would be really handy since there are
other tools to consume plain JSON and emit JSON Schema.

I'm considering taking a crack at a Julia output module for your project.
Those output adapters look pretty straightforward.

~~~
burntcaramel
Oh that would be great! Glad to hear it looks straight forward.

Ok will consider JSON Schema support. Thanks!

------
johnfn
Amazing. I was dreaming about writing a library to do exactly this during
Ludum Dare this weekend (I want strongly typed access to my tilemaps), and
here I find it on HN the next day. :)

~~~
bcherny
Funny how ideas tend to arise in unison :)

~~~
cunningfatalist
So true. We are working with TypeScript and JSON schema at the moment. I also
thought about writing something similar.

------
Myrannas
This library is great! My team uses it extensively to generate types for both
our server and client from our Api definitions (in RAML).

------
lolive
A message from the (now defunct) XML community:

We've gotten to a point where a human-readable, human-editable text format for
structured data has become a complex nightmare where somebody can safely say
"As many threads on xml-dev have shown, text-based processing of XML is
hazardous at best" and be perfectly valid in saying it. \-- Tom Bradford

------
stillbourne
I've been using this for a while now.
[https://github.com/JsonCSharpClassGenerator/JsonCSharpClassG...](https://github.com/JsonCSharpClassGenerator/JsonCSharpClassGenerator)

------
madeofpalk
Funny this comes up today. Right now I'm looking into how I can do pretty much
the exact opposite - take our Flow types and convert them to JSONSchema (or
anything else) that lets me validate an object against the type at runtime.

------
smrtinsert
I don't understand the need for this. You're writing a definition to create a
strongly typed class, why wouldn't you just write the class itself?

~~~
bcherny
It's a good question!

For any use case where there is a set of servers and a set of clients that
interact with those servers, you often end up having to hard-code API
contracts and response shapes on each client and each server.

If your client and server are written in the same language, you might be able
to write an interface/class once and share the code between both builds. But
what if (as is more often the case) they are written in different languages?
What if you introduce a 3rd client, written in a 3rd language (say C# on the
server, Swift on iOS, and Java on Android)?

This is what Google uses Protobuf for [0]. A competing solution is JSONSchema,
which gives a slightly different set of functionality than Protobuf.

You describe your interface once with JSONSchema, and compile it into
interfaces/classes for your various clients/servers to consume. This gives you
compile time safety, and eliminates the need to manually author these classes
and manually keep them in sync between platforms.

As you scale up the number of services/clients/servers you're running, a
system like this becomes not just helpful, but necessary to ensure that they
can all talk to one another.

[0] [https://developers.google.com/protocol-
buffers/](https://developers.google.com/protocol-buffers/)

------
z3t4
It's quite trivial for a static analyzer to distinguish between a "string" and
numeric value. So I think it's unnecessary to annotate : string : number, etc
it just adds noise to the code. If you want to catch real bugs, check the
parameters!

------
lolive
Today Javascript reinvented SOAP :)

~~~
SigmundA
Almost, still need a JSON file that describes HTTP API endpoints and then
something that can turn that into a Typescript proxy API to replace WSDL.

