...
- How will DI help us?
- Constructor bloat
- Protocol builders/schedules everywhere
- Massive builders, tons of components are touched by plumbing for multiple use-cases
- Spring - How will this help?
- Spring POC - https://github.com/hyperledger/besu/pull/4697
- Won't help with the best dependency graphs
- Dagger is way more light-weight
- Spring is infectious in the code-base (turns it into a spring project)
- Security issue in adding new dependencies (SPRING)
- Spring has its own dependencies
- Supply chain attack
- Refactor of the code is useful anyways to address architectural challenges - THEN add DI - starting with DI instead of evaluating a refactor or the architecture is not the right way to go
- Diego - Spring too big, maybe useful for some use-cases
- Danno - 3 Options for DI
- Dagger 2
- Spring (echoing concern of Diego)
- Might be heavyweight and not useful
- Rebuild protocol scheduler and refactor as an engineering challenge
- Biggest task is analyzing this
- EVM
- Data-structs/methods don't require complex assembly
Juice - Guice DI (DON'T DO IT
)3 options- Library use-cases need to be "framework free"
- Creating dependencies is more issues and reduces performance
- VERSIONING DEPENDENCIES
- Gary
- DI as a splitting off point for modular use-cases
- Better for handling privacy code
| Attachments |
|---|