In a perfect world, everyone would version their immutable apis and never introduce breaking changes.
But in reality co-workers could introduce breaking api changes.
There could potentially be a mismatch between the actual runtime json response and the static compile time typescript types.
This can cause runtime errors, but could be caught by the typechecker / developer at compile time.
So a good solution is to implement decoder functions at the boundaries of the application, which are run-time type checks, with some static types on top.
If the run-time type check fails, the endpoint could return an error, in the form of a boxed result type.
This is a great idea! Would definitely add an extra layer of protection.
Some things we should ensure (imo):
It needs to be optional in case consumers don't want the decoders for whatever reason
It needs to be lightweight to not bloat the consumers generated bundle sizes
It needs to have some level of configurability - for instance on what level to throw errors (errors, warnings, etc), and probably some pluggable way to handle errors when they happen
In a perfect world, everyone would version their immutable apis and never introduce breaking changes.
But in reality co-workers could introduce breaking api changes.
There could potentially be a mismatch between the actual runtime json response and the static compile time typescript types.
This can cause runtime errors, but could be caught by the typechecker / developer at compile time.
So a good solution is to implement decoder functions at the boundaries of the application, which are run-time type checks, with some static types on top.
If the run-time type check fails, the endpoint could return an error, in the form of a boxed result type.
Some examples and helper libraries:
https://github.com/nvie/decoders https://github.com/swissmanu/spicery https://github.com/gcanti/io-ts https://github.com/fabiandev/ts-runtime