TypeSchema a future to a type-safe web
On November 2020 I wrote the article “TypeSchema an alternative to JsonSchema” which received over the time some great responses. With this post I like to create a follow up post to reflect on the current state of TypeSchema and in general the API schema landscape and try to provide an outlook for the future.
Type safety
At first I like to talk about type safety. I think in general more and more developers really like type safety, because of this many dynamically typed languages like Javascript, PHP, Ruby or Python move towards a type system. TypeScript is probably the most popular example.
Type safety is also really great for developing client/server applications i.e. if your receive a JSON payload from an REST API it is much easier to work with this payload if you have a TypeScript interface which describes this payload, since you don`t need to guess any property names. This is probably also the reason why projects like tRPC are really growing.
With TypeSchema we have developed a JSON format to describe data models in a language neutral format. A TypeSchema can be easily transformed into type safe code for almost any programming language. This helps to reuse core data models in different environments.
TypeHub
Our newest addition to the TypeSchema ecosystem is the TypeHub platform. TypeHub is a collaborative platform to design open data specifications, it is like GitHub for data modelling.
Through TypeHub you can easily create a new TypeSchema specification using our online editor. Then you can create a tag to release a specific version of your specification, TypeHub will automatically create a fitting changelog for every version. Users can also create a pull request to suggest changes to an existing schema. In the future we imagine that TypeHub can be a central place where developers can share and contribute to open data specifications.
The current API landscape
In my view OpenAPI is still the primary specification to describe REST APIs. The goal of the OpenAPI spec is to describe many different REST API variations. The most prominent use case of OpenAPI is probably to create a great documentation based on the specification, which currently works really well. There are many multiple vendors and tools which help to create developer portals or documentation based on an OpenAPI spec.
In the past I had the hope to integrate TypeSchema into the OpenAPI spec so that developers could opt in to use TypeSchema instead of JsonSchema to describe JSON payloads. Over the time I have given up on this idea since they have moved to a deeper JsonSchema integration and I also realized that in the end this would make the spec an even greater integration mess, since you already need to understand the OpenAPI and JsonSchema spec which is in detail a complicated thing, if you then also need to factor in a different spec it does not make sense.
The future
We still think that a type safe API ecosystem is a goal which we should pursue. TypeSchema builds the foundation for such an ecosystem, which allows us to describes data models in a language neutral format.
Based on this we are currently working on a new specification called TypeAPI. The goal of TypeAPI is to have a specification which allows us to generate fully typed client and server code for different programming languages.
We hope that we can help with this specification to move to a complete type safe API ecosystem which should make API integration far more easy then it is today. Once we have a first version released I will also create a dedicated post to cover the details.
So I hope I could give you an overview of the current state of TypeSchema and our ideas to build a type safe API ecosystem. Please stay tune and let me know if you have any further ideas or questions.
