Idea of the archiecture explained

[nivida]

Any real logic should be implemented in the internal codebase. The public API layer should use those objects and functions. This will encapsulate the public API from the actual codebase and gives us a lot of flexibility. But to still provide neat import paths did I add a custom publish pipeline as we know from other big projects in the JS ecosystem.

If web3.init does get called in the index file of the depending project is one global config existing. This configuration will get pre-inject if no custom config does get passed to the called function or initiated object.

... and much other stuff I already thought out.

Things this project does follow:

• As dependency less as possible but don't reinvent the wheel all the time
• Clean Code
• SOLID
• DDD (as it does make sense in JS)
• Wisdom of Martin Fowler
• Wisdom of Uncle Bob

[nivida]

The public API layer should

... provide all functionalities as functions and will have objects to aggregate those functions as for example the Transaction object from the POC. This will improve the DX in some cases. Such wrapping objects on the public API layer should only get added if it actually does make sense. e.g: A Eth object doesn't have to exist.

[nivida]

Factories for DI:

It is not possible to use factories as in other languages. This because of the impact it will have on the bundle size. We could create many small Factory objects or we handle the DI completely on the public API layer.

Edit: The third option would be to ignore DI. But this will probably increase the unit test complexity and will lead to un-mocked external dependencies without even noticing it.