Modifications to Timber allowing it to work with multiple contracts.
TLDR:
With each request, Timber reads the contractId from the incoming request and builds a model with the appropriate collection name through the assign-db-connection middleware.
As a result, Timber will know where to insert new nodes and which collection to read the data from without mixing data from many contracts or accidentally overwriting it.
Other important changes:
Timber now requires a new environmental variable CONTRACT_API_ENDPOINT which is required to work with multiple contracts. It resolves the contractId to an actual address and provides information about the contract's deployment block (getFromBlock() from merkle-tree/src/filter-controller.js).
If it's not present, Timber will still work as usual, but will not be able to work with multiple contracts.
Modifications to Timber allowing it to work with multiple contracts.
TLDR: With each request, Timber reads the
contractId
from the incoming request and builds a model with the appropriate collection name through theassign-db-connection
middleware.As a result, Timber will know where to insert new nodes and which collection to read the data from without mixing data from many contracts or accidentally overwriting it.
Other important changes:
Timber now requires a new environmental variable
CONTRACT_API_ENDPOINT
which is required to work with multiple contracts. It resolves thecontractId
to an actual address and provides information about the contract's deployment block (getFromBlock()
frommerkle-tree/src/filter-controller.js
).If it's not present, Timber will still work as usual, but will not be able to work with multiple contracts.