v23-beta

[adrianhopebailie]

Refactor connector for more flexible config and ability to cluster multiple instances for a composite connector.

This is the outcome of the experiments done by @DonChangfoot @matdehaast and me over the last few weeks.

It is not quite ready for release but we'd like to get feedback asap.

Still TODO is to add integration tests for new topologies. Please provide feedback on topologies being used in the wild to assist us with this.

Changes:

• Extracted some core types into their own schema
• Added a new Account type which represents an account on the connector. It may wrap a plugin but may also simply be a proxy to another connector.
• New Account objects are provided by pluggable AccountProvider objects. The default implementation is being the PluginAccountProvider which instantiates a new Account for each plugin in the configuration or in response to app.addPlugin().
• A connector running a ServerAccountProvider is intended to replace the various "asym-server" plugins in use today based onmini-accounts. This provider listens on a single port for new clients and then creates a newAccount` for each incoming connection.
• Added configuration profiles which allow the app to be run in connector or plugin mode. In plugin mode the connector behaves like a stand-alone plugin hosting just that one plugin and the middleware configured for it. The connector will have a single uplink to another connector and will not have any routing functionality.
• Removed support for the v1 plugins (this was pulling in a LOT of legacy code)
• Modified middleware to pass deserialised packets down the pipeline (i.e. packets are deserialised and serialised once.)
• Modified package structure to be closer to other TypeScript projects
• Added load testing via a JMeter Docker container (to be published)

Notes:

The new architecture has resulted in some optimisations which need to be thoroughly tested. One of these is that the app handles new accounts asynchronously. When the Account is created it is passed to the app which then calls Account.startup() before starting to track the account in the routing service and reloading the routing tables. This can mean there is a small delay between adding an account and being able to route messages to that account.

[codecov-io]

Codecov Report

Merging #476 into master will decrease coverage by 0.24%. The diff coverage is 74.1%.

@@            Coverage Diff             @@
##           master     #476      +/-   ##
==========================================
- Coverage   73.62%   73.37%   -0.25%     
==========================================
  Files          44       53       +9     
  Lines        2059     2235     +176     
  Branches      332      348      +16     
==========================================
+ Hits         1516     1640     +124     
- Misses        543      595      +52

Impacted Files	Coverage Δ
src/backends/ecb.ts	59.09% <0%> (ø)	:arrow_up:
src/common/log.ts	100% <100%> (ø)	:arrow_up:
src/middlewares/stats.ts	100% <100%> (+31.25%)	:arrow_up:
src/services/route-builder.ts	90.38% <100%> (ø)	:arrow_up:
src/middlewares/error-handler.ts	94.11% <100%> (+29.83%)	:arrow_up:
src/middlewares/expire.ts	100% <100%> (+5.26%)	:arrow_up:
src/types/account-provider.ts	100% <100%> (ø)
src/middlewares/max-packet-amount.ts	100% <100%> (+4.34%)	:arrow_up:
src/services/routing-table.ts	100% <100%> (ø)	:arrow_up:
src/services/rate-backend.ts	100% <100%> (ø)	:arrow_up:
... and 48 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update a7c4bcd...59efb2e. Read the comment docs.

[matdehaast]

We also need to do a check with moneyd and this new branch

[sharafian]

Can this be closed? Seems like it was superseded by rafiki

[adrianhopebailie]

These ideas were incorporated into Rafiki: https://medium.com/interledger-blog/introducing-rafiki-e3de4710d3de