if we will need to change something in database representation (optimisation/fix/field name change) this will suddenly break our api, which at some point will expected to be stable by external consumers
not everything in db needs to be exposed to users of api.
types for api consumption may be different i.e for example db we can use []byte but in api we perfectly would use hex encoded strings
This story is about improving this situation across every module in Babylon node. The whole migration to make our node API production ready should look roughly:
Create API types in every module and write code translating between transalting db types to api types
After we have proper responses type we need to review them and decide which fields are really necessary and remove the unnecessary ones to have nice clean minimal API. We have large set or programs (dashboard/vigiilantes/reporters) to guide us in this trimming effort.
After we have nicely trimmed api, we may consolidate some practices around it so that endpoints are consistent across different modules.
Currently in Babylon node in API responses we return types directly used in database:
https://github.com/babylonlabs-io/babylon/blob/5f8af8ced17d24f3f0c6172293cd37fb3d055807/x/btclightclient/keeper/grpc_query.go#L25 which just return BTCHeaderHashBytes in straight from db
This is not ideal as:
if we will need to change something in database representation (optimisation/fix/field name change) this will suddenly break our api, which at some point will expected to be stable by external consumers
not everything in db needs to be exposed to users of api.
types for api consumption may be different i.e for example db we can use []byte but in api we perfectly would use hex encoded strings
This story is about improving this situation across every module in Babylon node. The whole migration to make our node API production ready should look roughly:
Create API types in every module and write code translating between transalting db types to api types
After we have proper responses type we need to review them and decide which fields are really necessary and remove the unnecessary ones to have nice clean minimal API. We have large set or programs (dashboard/vigiilantes/reporters) to guide us in this trimming effort.
After we have nicely trimmed api, we may consolidate some practices around it so that endpoints are consistent across different modules.