[Meta] Investigate making endpoints "pluggable" from external modules #488
Labels
I8 - Enhancement
Additional feature request
I9 - Meta
Meta discussions about Sidecar
P5 - Sometime Soon
Worth doing soon
Q3 - Medium
Requires decent knowledge of Sidecar/Substrate
Currently, any endpoints that sidecar exposes must have all their code live in this repo. So, if a chain wants an endpoint in this service they would need to make a PR, have it approved, and make maintenance PRs here.
Given that substrate chains have vastly different needs and the upper bound on unique projects is undefined it is unreasonable to expect that the maintainers of api-sidecar will be to include and maintain chain specific endpoints for every substrate chain out there. Thus, in order to make api-sidecar more extensible while keeping core maintenance load stable, pluggable endpoints should be investigated.
At the moment I see two primary directions this could go:
Allow additions of packages or specific files that specify endpoints that can be mounted generically onto an express router. This could be done through configuration variables pointing to packages or specific files that live outside of the repo. Largely though, the internal service architecture would stay the same and chain specific functionality would just extend the existing service.
Break up the existing api-sidecar into packages, where core functionality is in one package, and routes distributed in other packages (i.e. staking-api-routes, pallets-api-routes, accounts-api-routes etc). Then, each chain builder could have there own sidecar (polkadot-api-sidecar, statemint-api-sidecar, etc) declaratively composed using the core package, and any other packages of compatible routes and they could add their own chain specific routes on a as needed basis. This would be in a similar vein to txwrapper-core and allow chain builders to have complete control and responsibility for their own api-sidecar micro service.
The text was updated successfully, but these errors were encountered: