What follows is an overview of the sdk, and the features it provides for app development. If you have not yet read the overview of the databox, it may be worth doing so before continuing. It is worth noting from the outset that the SDK is no silver bullet; it is well suited to building lightweight apps that operate on data to perform actuation or data visualisation; more complex apps (e.g. those that require significant user interaction, or complex data processing) will inevitably require developers to fall back to code; there are good examples of databox apps written in a variety of languages at the main databox repo
There isn’t all that much to a databox app. It is simply:
All databox apps are run inside docker containers connected to a network that appropriately restricts interaction with other databox components. A datastore is the primary mechanism by which an app communicates with a datasource. A datastore is both a (i) repository of data from a datasource, and (ii) an endpoint for performing actuation. All communication with a datastore is through an API. We are not prescriptive about the language that an app is written in, only that it uses the databox APIs for registering with the system and reading and writing from/to datastores. Currently we have libraries that simplify calls to the API written for nodejs, python and go.
Apps built in the SDK is loosely modelled on flow-based programming. Apps are built as directed graph of black boxes with well-defined input and output interfaces (ports) connected by edges. We are principally concerned with data flow; data (information packets) flows along edges, in and out of nodes and is processed and modified along the way. There are 3 principle types of node that you’ll work with:
SDK datastores differ slightly from the databox notion of a datastore in that they are only originators of data; they do not perform actuation - this is performed by output nodes.
Outputs are the endpoints of a flow, they with typically perform some kind of actuation (turn a bulb on, send a tweet) or display (present a visualisation, graph etc).
All nodes in the SDK provide interfaces for configuration - these can be very rich, and may operate as comprehensive tools in their own right. For example the ‘uibuilder’ processing node provides a vector-based graphs tool for attaching incoming data to components of an svg image. All nodes also come with comprehensive help; perhaps the most important is an overview of the data schemas that they expect and/or output.
The end-to-end databox app workflow process can be broken down into several stages:
The SDK is principally concerned with the first 5 i.e:
The purpose of the databox SDK is to streamline each of these stages to get you building and deploying apps as efficiently as possible. The databox dashboard supports stages 6-9.