It is type safety at runtime.
Typescript gives you some type safety at develop time (like jsdoc also can do)
But if I read it right, this helps you to generate OpenAPI spec to validate the api endpoints, to get easy type safety at runtime.
See also e.g. https://openapistack.co/docs/openapi-backend/intro/ that is also helping to be type safe at runtime.
Or Nest can also generate OpenAPI als validation based on it.
Only difference is that OpenAPI stack is design first, and Instant is code first.
And Nest use decorators and Instant JSDoc.
It is more like https://www.npmjs.com/package/swagger-jsdoc that generate the OpenAPI from JSDoc.
To use Typescript or not doesnt matter, it is about runtime validation.
The one like the native JS way with JSDoc, the other likes Typescript and doesnt matter the build step for the API.
Write a specification of your endpoints in TypeScript, and from that one spec you get:
- Server side validation of requests/responses
- A TypeScript API client
- Specialized clients, if you like, for example a react-query client if you like using react-query
- Auto-generated docs (OAS)
- TypeScript types for requests and responses to use in your code
IMO a lot more maintainable than a jsdoc based approach. For example, you can define a type for a Person, and then re-use that type in the responses of all Person-related endpoints, and even in POST/PUT/PATCH bodies (saying things like “the POST body is a person Person, but omit the id field”). With jsdoc you’re repeating that definition a tonne, AND you’re lacking compile time type safety.
To use Typescript or not doesnt matter, it is about runtime validation. The one like the native JS way with JSDoc, the other likes Typescript and doesnt matter the build step for the API.