13 releases (1 unstable)
new 28.9.0-non-semver-compat | Jul 9, 2025 |
---|---|
28.8.0-non-semver-compat | Jul 8, 2025 |
28.7.0-non-semver-compat | Jun 30, 2025 |
28.3.0-non-semver-compat | May 30, 2025 |
0.1.0 | Jul 15, 2024 |
#640 in Magic Beans
414 downloads per month
Used in 9 crates
87KB
1.5K
SLoC
ZKsync Node DI Framework
This is a dependency injection (DI) library used by the ZKsync node binaries (zksync_server
and
zksync_external_node
). The library is designed to be fully generic, so it doesn't incorporate any ZKsync-specific
domain knowledge.
Usage
The library provides following DI abstractions:
- Resources are provided or requested by node components. An example of a resource is a Postgres connection pool factory.
- Components may also provide tasks managed by the framework.
- Requesting and providing resources / tasks is encapsulated in wiring layers.
Wiring layers are defined in a decentralized way in component crates and some lower-level libraries and are assembled together in the node binary using the service builder.
How to work with DI
Define DI logic in the separate node
module of your crate.
For lower-level libraries, the module should be gated behind an opt-in node_framework
feature (i.e., via
#[cfg(feature = "node_framework")]
). Correspondingly, the node framework should be an optional dependency, together
with any auxiliary node-specific dependencies:
[dependencies]
zksync_node_framework = { workspace = true, optional = true }
[features]
default = []
node_framework = ["dep:zksync_node_framework"]
The node framework should not require many additional deps, maybe health checks and/or shared DI resources; if it requires heavyweight deps, you're probably doing something wrong. The reasoning behind feature-gating is that it's reasonable to assume that lower-level libraries may be used outside node binaries.
For node components, no feature-gating is necessary, but node framework logic should still be placed in the node
module, not scattered across the crate.
Dependencies
~4–13MB
~156K SLoC