Please add the labels corresponding to the type of changes your PR introduces:
Feature
What is the current behavior?
Resolves: #NA
What is the new behavior?
Introduction of versions for our RPC API.
Versions are defined in the mc-rpc::versions module, organized as follow:
versions
├── mod.rs
└── v0_7_1
├── mod.rs
├── api.rs # contains the API definition of the current version
└── methods # contains all the methods implementation
├── mod.rs
├── read/
├── trace/
└── write/
All the implementations are then merged in our RpcModule in the versioned_rpc_api function.
Methods will be version-prefixed to avoid collisions, for example:
starknet_V0_7_1_blockNumber,
starknet_V0_8_0_blockNumber
etc...
The "routing" is done in the VersionMiddlewareLayer middleware, where depending on the version provided in the route by the request's user, we forward to the right method.
If no version is provided, the latest RPC version available is used, defined in RpcVersion::RPC_VERSION_LATEST.
Does this introduce a breaking change?
No
Possible improvement
I don't like the current process of adding a new version ; it is:
Create a new constant in the RpcVersion primitive, like: pub const RPC_VERSION_0_7_1: RpcVersion = RpcVersion([0, 7, 1]);
Add it in the SUPPORTED_RPC_VERSIONS array,
Add the version API + implementation in the mc-rpc::versions module,
Add the module when merging the API methods:
pub fn versioned_rpc_api(starknet: &Starknet, read: bool, write: bool, trace: bool) -> anyhow::Result<RpcModule<()>> {
let mut rpc_api = RpcModule::new(());
merge_rpc_versions!(
rpc_api, starknet, read, write, trace,
v0_7_1, // We can add new versions by adding the version module below
// , v0_8_0 (for example)
);
// ...
Lot of dependency between objects, the middleware also uses the SUPPORTED_RPC_VERSIONS array for routing.
It is fine though because we don't have new versions everyday, that's an uncommon event.
But happy to hear your suggestions!
Diff Coverage details (click to unfold)
### crates/node/src/service/rpc/middleware.rs
`48.33333333333333%` of new lines are covered
### crates/client/rpc/src/versions/v0_7_1/methods/read/lib.rs
`0.0%` of new lines are covered
### crates/client/rpc/src/versions/v0_7_1/api.rs
`100.0%` of new lines are covered
### crates/proc-macros/src/lib.rs
`88.70967741935485%` of new lines are covered
### crates/client/rpc/src/test_utils.rs
`0.0%` of new lines are covered
### crates/node/src/service/rpc.rs
`100.0%` of new lines are covered
### crates/node/src/main.rs
`100.0%` of new lines are covered
### crates/node/src/service/rpc/server.rs
`100.0%` of new lines are covered
### crates/primitives/chain_config/src/rpc_version.rs
`87.73584905660377%` of new lines are covered
### crates/client/rpc/src/lib.rs
`75.0%` of new lines are covered
Pull Request type
Please add the labels corresponding to the type of changes your PR introduces:
What is the current behavior?
Resolves: #NA
What is the new behavior?
Introduction of versions for our RPC API.
Versions are defined in the
mc-rpc::versions
module, organized as follow:All the implementations are then merged in our
RpcModule
in theversioned_rpc_api
function.Methods will be version-prefixed to avoid collisions, for example:
starknet_V0_7_1_blockNumber
,starknet_V0_8_0_blockNumber
The "routing" is done in the
VersionMiddlewareLayer
middleware, where depending on the version provided in the route by the request's user, we forward to the right method.If no version is provided, the latest RPC version available is used, defined in
RpcVersion::RPC_VERSION_LATEST
.Does this introduce a breaking change?
No
Possible improvement
I don't like the current process of adding a new version ; it is:
RpcVersion
primitive, like:pub const RPC_VERSION_0_7_1: RpcVersion = RpcVersion([0, 7, 1]);
SUPPORTED_RPC_VERSIONS
array,mc-rpc::versions
module,Add the module when merging the API methods:
Lot of dependency between objects, the middleware also uses the
SUPPORTED_RPC_VERSIONS
array for routing.It is fine though because we don't have new versions everyday, that's an uncommon event. But happy to hear your suggestions!