Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate database proto types from external API proto types in Babylon node #537

Open
RafilxTenfen opened this issue Mar 7, 2024 · 0 comments
Assignees

Comments

@RafilxTenfen
Copy link
Contributor

Currently in Babylon node in API responses we return types directly used in database:

https://github.com/babylonchain/babylon-private/blob/dev/x/btcstaking/keeper/grpc_query.go#L71 which just return delegations in straight from db

https://github.com/babylonchain/babylon-private/blob/dev/x/btclightclient/keeper/grpc_query.go#L71 which return headers as they are stored in 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant