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

[Meta] Investigate making endpoints "pluggable" from external modules #488

Open
emostov opened this issue Mar 23, 2021 · 1 comment
Open
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

Comments

@emostov
Copy link
Contributor

emostov commented Mar 23, 2021

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:

  1. 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.

  2. 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.

@emostov emostov added 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 labels Mar 23, 2021
@TarikGul
Copy link
Member

TarikGul commented Mar 23, 2021

I really think both 1 and 2 are very valid solutions, but that being said, I think 2 would be the most applicable, and maintainable across the board. Having everything in one place seems the most logical to me.

1 seems like a quicker more practical solution for short term gain, but 2 is very net-positive via long term thinking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

2 participants