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/

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

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.

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.

Consider that the JSONSchema may already exist.