A Kite client library for the browser and node.js
npm install kite.js
In node:
var Kite = require('kite.js');
Or, alternatively, if you want to use the promises-based api:
var Kite = require('kite.js/promises');
In the browser:
<script src="./browser/kite-bundle.js"></script>
Or:
<script src="./browser/kite-bundle-promises.js"></script>
After which point you can require it like this:
var Kite = require('kite');
you can use the Kite
constructor with a URL:
var Kite = require('kite');
k = new Kite('ws://my-math-service.com');
k.tell('square', [4], console.log.bind(console));
// logs "null 16"
Open a connection to the remote service. Called the first time in the constructor.
Close the connection, if it is open.
Send an RPC to the remote service, and receive the response.
If you are using the promisified library, the callback is optional. Of course, you should use promises instead of passing callbacks if you choose to use the promisified library.
var params = {
query: { /* kontrol query */ }
who: { /* kite.who query */ }
}
The kontrol query is used by kontrol to select matching kites by the following criteria, which are order from general to specific:
type KontrolQuery struct {
username string
environment string
name string
version string
region string
hostname string
id string
}
The order matters, and more general criteria cannot be omitted. In other words, if you want to query by name
, you must also provide values for username
and environment
; if you want to query by region, you need to provide values for all of username
, environment
, name
and version
.
Kite descriptors are provided by kontrol, and look like this:
var kiteDescriptor = {
kite: {
name: "A Kite Name",
version: "1.0.0"
},
token: "A token provided by kontrol",
url: "wss://example.com/sample-kite"
};
Kites can implement custom load-balancing strategies for other instances of their kind. This works by delegation: First kontrol will query for any kite matching the given criteria; If it matches one, it will forward the kite.who query to the kite.who
method a matching kite. The contents of the kite.who query are application-layer concerns, and are not scrutinized by kontrol, which merely forwards them along to the target kite. The target kite can treat this information however it likes, but is required to respond to the kite.who
method with a new query that will match the kite which is designated to be the new target kite. It is acceptable for the kite to respond with a query matching itself.
This can be useful if the kite is using some kind of session state. If a given kite has already allocated resources or has some state stored locally, the user can be reconnected to that instance via this mechanism.
This method will respond with any kites that matched the query, after any potential load balancing negotiation.
The matching kites will not be connected. You can connect to one by calling its .connect()
method.
This works by querying using fetchKites, and then simply choosing one of the kites matching the given query, after load balancing negotiation.
This works like fetchKites
, but will also stream through any updates matching the query as they occur. It will respond with an additional parameter, the watcherID
which is a numeric handle that can be used to cancel that watchKites
operation.
This feature won't work in conjunction with kite.who
Given the numeric watcherID
handle provided by watchKites
, cancelWatcher
can be used to clear the associated watch operation.
Given a kite descriptor, this method will instantiate a proper Kite
instance.
The MIT License (MIT) - see LICENSE for more details