Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • 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 -
    • 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
    1. Dagger 2
    2. Spring (echoing concern of Diego)
      1. Might be heavyweight and not useful
    3. Rebuild protocol scheduler and refactor as an engineering challenge
      1. Biggest task is analyzing this
    • EVM
    • Data-structs/methods don't require complex assembly
    • Guice DI (DON'T DO IT
  • )3 options
    • Library use-cases need to be "framework free"
    • Creating dependencies is more issues and reduces performance
  • Gary
    • DI as a splitting off point for modular use-cases
    • Better for handling privacy code