search

paritytech / substrate-api-sidecar

REST service that makes it easy to interact with blockchain nodes built using Substrate's FRAME framework.
https://paritytech.github.io/substrate-api-sidecar/dist/
GNU General Public License v3.0
246 stars 151 forks source link

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

Open emostov opened 3 years ago

emostov commented 3 years ago

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.

TarikGul commented 3 years ago

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.