I’m working on a library with a similar approach for Node/TypeScript. Obviously the language and platform semantics differ (and unlike several TypeScript API libraries I will be intentionally avoiding decorators because TS/TC39 decorators differ), but it’s nice to see a similar approach validated on a platform with a better reputation for thoughtful design.
I have built another version of this, internal for a previous employer, and it’s been proven successful. It’s really great to have API boundary validation, automatic documentation and static type validation all from a single, simple and declarative source of truth. And I’ve seen first hand how it can improve developer productivity and confidence, project maintainability, and API user experience.
In my experience, Python has a better foundation for this kind of approach: better underlying libraries available in the ecosystem, more likely to work well together. I’ve taken a lot of inspiration from that and hope to at least set a better example for the Node/TS world.
I have built another version of this, internal for a previous employer, and it’s been proven successful. It’s really great to have API boundary validation, automatic documentation and static type validation all from a single, simple and declarative source of truth. And I’ve seen first hand how it can improve developer productivity and confidence, project maintainability, and API user experience.
In my experience, Python has a better foundation for this kind of approach: better underlying libraries available in the ecosystem, more likely to work well together. I’ve taken a lot of inspiration from that and hope to at least set a better example for the Node/TS world.