7 ms·

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?

spankalee 9y ago
Consider that the JSONSchema may already exist.
zeugmasyllepsis 9y ago
I'm not the author, but I assume the intent is to allow you to share the JSONSchema definition between the front-end and back-end. For example, a developer could write an annotated .NET class using the Json.NET schema library from Newtonsoft[1], automatically generate the schema for that class, then use this project to compile that schema into an equivalent TypeScript class. Or go the other way around (TypeScript -> JSONSchema -> .NET class). Or start from the middle with a JSONSchema. Alone, you're right, this project doesn't make much sense, but it's part of a larger community of tools for creating cross-language model definitions based on a common schema language. [1] : http://www.newtonsoft.com/jsonschema http://www.newtonsoft.com/jsonschema
beaconstudios 9y ago
TypeScript doesn't produce any runtime code for validating types - this is good for data inputs from untrusted sources where you want to type in TypeScript at compile-time but still validate against the schema at runtime.
nicholasjarnold 9y ago
Almost all of our service endpoints were designed API-first with JSON Schema and AJV validation. I could see this being useful for us to get TS models generated quickly for the UI team rather than hand-coding them for all of our existing schemas during our move to using TS/Angular.
bcherny 9y ago
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/

spankalee 9y ago

Consider that the JSONSchema may already exist.

zeugmasyllepsis 9y ago

I'm not the author, but I assume the intent is to allow you to share the JSONSchema definition between the front-end and back-end. For example, a developer could write an annotated .NET class using the Json.NET schema library from Newtonsoft[1], automatically generate the schema for that class, then use this project to compile that schema into an equivalent TypeScript class. Or go the other way around (TypeScript -> JSONSchema -> .NET class). Or start from the middle with a JSONSchema. Alone, you're right, this project doesn't make much sense, but it's part of a larger community of tools for creating cross-language model definitions based on a common schema language. [1] : http://www.newtonsoft.com/jsonschema http://www.newtonsoft.com/jsonschema

beaconstudios 9y ago

TypeScript doesn't produce any runtime code for validating types - this is good for data inputs from untrusted sources where you want to type in TypeScript at compile-time but still validate against the schema at runtime.

nicholasjarnold 9y ago

Almost all of our service endpoints were designed API-first with JSON Schema and AJV validation. I could see this being useful for us to get TS models generated quickly for the UI team rather than hand-coding them for all of our existing schemas during our move to using TS/Angular.

bcherny 9y ago

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/