So currently there's two main logic areas:
The Cluster or (app.js)
and
The Sync script.
The Cluster/app.js merely is just the explorer itself that controls the express webapp. However, this also is our linkage point to the backend coin which the Sync script relies on.
The Sync script, currently just a simple "start from Block 1 (or last sync'd block) and go up from there" sends all of its API calls to app.js and that communicates out to the wallet based on settings.json.
There's not much really stopping us from turning this into a multi-coin explorer if a few things are done first.
1) Remove "last txes" from the index page and instead give a menu/listing of coins we're indexing.
2) Change calls like /api/gettransaction? to something like /api/btc/gettransaction. Basically add a coin variable to calls.
3) Remove the sync tool from needing to use app.js at all. In theory we have enough traffic already hitting the webserver, we really don't need more from internal. Also, the webserver itself doesn't necessarily need bitcoin-core/bitcoin-node-api module for much that we can't offload somewhere else.
Number 3 is where things would probably get tricky, but my theory is this:
1) We're already needing a separate server for the daemon(s) unless you're letting them run on the same system which could lead to performance issues with users. Each daemon should have its own "sync.js application" that uses bitcoin-core (bitcoin-node-api is an express webapp wrapper for bitcoin-core) directly. This removes 1 additional request query from happening and would hopefully speed things up.
2) Each sync.js application therefore updates the mongodb which our frontend will read and display data from.
So currently there's two main logic areas: The Cluster or (app.js) and The Sync script.
The Cluster/app.js merely is just the explorer itself that controls the express webapp. However, this also is our linkage point to the backend coin which the Sync script relies on.
The Sync script, currently just a simple "start from Block 1 (or last sync'd block) and go up from there" sends all of its API calls to app.js and that communicates out to the wallet based on settings.json.
There's not much really stopping us from turning this into a multi-coin explorer if a few things are done first.
1) Remove "last txes" from the index page and instead give a menu/listing of coins we're indexing. 2) Change calls like /api/gettransaction? to something like /api/btc/gettransaction. Basically add a coin variable to calls. 3) Remove the sync tool from needing to use app.js at all. In theory we have enough traffic already hitting the webserver, we really don't need more from internal. Also, the webserver itself doesn't necessarily need bitcoin-core/bitcoin-node-api module for much that we can't offload somewhere else.
Number 3 is where things would probably get tricky, but my theory is this: 1) We're already needing a separate server for the daemon(s) unless you're letting them run on the same system which could lead to performance issues with users. Each daemon should have its own "sync.js application" that uses bitcoin-core (bitcoin-node-api is an express webapp wrapper for bitcoin-core) directly. This removes 1 additional request query from happening and would hopefully speed things up. 2) Each sync.js application therefore updates the mongodb which our frontend will read and display data from.
to be continued.