You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Building a switch is no easy task. libp2p being a modular system, we have to build 10s of objects, in a particular order, and ideally in a quite generic way
Code outside of libp2p cannot be integrated into it
It needs to import every module of libp2p that it can build, even if the user doesn't care about said module (especially bad when the module imports optional dependencies, like the transports)
Every time we add something to libp2p, we also need to add it to this file
It's quite hard to maintain
With that in mind, we need to find a new system.
A good starting point might be to look at other libp2ps, and how to they build their switches.
Last time I did this exercice, I've seen that they mostly used hard-coded builders like ours, but go-libp2p wanted to switch to a dependency injection pattern.
AFAIK, we don't have a good DI library in Nim, so I've started a PoC a few years ago: #701
However, it's quite rough, and needs more work
The text was updated successfully, but these errors were encountered:
Building a switch is no easy task. libp2p being a modular system, we have to build 10s of objects, in a particular order, and ideally in a quite generic way
The current builder system has a few flaws:
With that in mind, we need to find a new system.
A good starting point might be to look at other libp2ps, and how to they build their switches.
Last time I did this exercice, I've seen that they mostly used hard-coded builders like ours, but go-libp2p wanted to switch to a dependency injection pattern.
AFAIK, we don't have a good DI library in Nim, so I've started a PoC a few years ago: #701
However, it's quite rough, and needs more work
The text was updated successfully, but these errors were encountered: