Buslane

Intro

Buslane is a cross-service and transparent object.method proxy, using an rpc-lite json/http1 transport.

The need for this lib came about when we decided to move to docker at 5app. I wanted a simple way to remove our direct code dependencies between services without having to add extra endpoints manually.

With buslane and its RPC like object proxying, you can call methods on remote objects as if they were in the same context. So there is no need to create specific service endpoints either. Just write the configuration and buslane will expose the objects to each other.

This is all still very experimental, so use with caution, I sure am.

Config & Usage

Install the buslane package using:

npm install --save @5app/buslane

Now, you will need to create a Buslane instance which you can use to make service1 and service2 communicate:

const Buslane = require('@5app/buslane');

const thisServiceName = 'service1';
const config = {
	name: thisServiceName,
	shared_api_key: 'my shared secret key',
	map: [
		{name: 'service2', port: 11211, ingresses: ['boat']},
		{name: thisServiceName, port: 11311, ingresses: []},
	],
};

const buslane = new Buslane(config);
const rpcResult = await buslane.service2.boat.sail('ocean');

Test

build and run with docker:

docker build -t buslane . && docker run buslane

Comparison with Buslane 2

Buslane 3 uses HTTP1 while Buslane 2 uses HTTP2. The decision on dropping HTTP2 in favour of HTTP1 was made in order to resolve 2 issues:

• Recover connections after the service recovers: this can also be achieved by re-attempting connections and handling extra HTTP2 headers like GOAWAY (in addition to the current ERR_HTTP2_INVALID_SESSION).
• Load balancing requests between multiple instances of the same service: HTTP2 creates a session which binds 2 services (instances) together using a TCP connection. As a session-less protocol, HTTP1 does not have this issue, but on the other hand, there will be a handshake every time a request is made (with extra overhead compared to HTTP2).