Crypto platform update - Refactoring the backend service

As I briefly touched in my original post, my platform is roughly separated into a front-end webapp and a back-end set of node services. For my original tests, this served its purpose well enough. I was content with keeping a separation of concerns when it comes to processing different types of information, but communication between the various services relied on a common event bus in the front-end. I needed to change that.

My original strategy was based around simply creating a plain Javascript file and running it through node. This was simple, but inefficient. I couldn't take advantage of the neat features offered by babel and webpack. I added a new build step to the list, so the build process now includes:

• Main - The main Electron process
• Renderer - The Electron browser process
• Web - Static files
• Backend - The new service module

Instead of creating a Vue component for each service, I now have a single, narrowly-focused component that pipes data to/from the backend. I have removed the service bus completely, and added a test page within my app to monitor data within the service.

I can now refactor my backend to include some neat features from both babel for ES6 support and webpack for its additional require options. It allows me to write a series of interfaces (coming from C++ background) that define common functionality. Currently, I have the following interfaces:

• base-wallet.js
• base-exchange.js
• base-indicator.js
• base-bot-strategy.js

I can utilize ES6's classes to extend these interfaces for each supported module.

• wallets/btc.js
• wallets/doge.js
• exchanges/bittrex.js
• exchanges/gdax.js

Finally, I can load them all in cleanly:

const wallets = {};
const exchanges = {};

const wallet_files = require.context('./wallets', false, /\.js$/)
const exchange_files = require.context('./exchanges', false, /\.js$/)

wallet_files.keys().forEach(key => {
    try {
        wallets[key.replace(/(\.\/|\.js)/g, '')] = wallet_files(key).default;
    } catch(err) {
        process.send({message:`unable to add wallet ${key}`});
    }
});

exchange_files.keys().forEach(key => {
    try {
        exchanges[key.replace(/(\.\/|\.js)/g, '')] = exchange_files(key).default;
    } catch(err) {
        process.send({message:`unable to add exchange ${key}`});
    }
});

// Module validation goes here

The biggest benefit here is that I can keep a separation between local and remote backends. My webpack configuration allows me to build both variations easily, with minor adjustments to account for differences between a local IPC channel and a remote websockets connection.

On IPC

I love how gracefully nodejs handles this. I have attempted to replicate Chromium's IPC setup in past C++ projects, and they became unwieldy and difficult to work with. I would need to hunt down and bring in another library, such as Boost's wonderful IPC library. I would then need to add it to CMake, test the various configurations to ensure it builds properly, and then I can actually use the library. Then I need to deal with creating a shared memory pool, serializing/deserializing objects, and all the associated headaches.

Here, the IPC channel is setup for me the moment I fork the child process. It automatically handles Javascript objects for me