Databases are meant to store data, but how do you easily extend the functionality of your database? In the same simple way, Outerbase opens up your database to view, visualize, and manipulate data, Commands allow anyone with a little bit of code to make that data accessible to anyone over HTTP.

Please note that this feature is currently in beta and we appreciate any feedback you may have.

You can now build APIs, add server-side logic to your Outerbase plugins (coming soon) and execute them against your database all without thinking about infrastructure.

Composition

Commands are made up of one or more Nodes that can be authored in any supported language. Each Base in your Workspace shares the same “base” URL giving each command a unique HTTP Path.

Paths in your Command’s Base can utilize any HTTP Verb (GET, POST, PATCH, PUT, DELETE) and path combination. Once the verb+path is chosen, then the node itself can be coded.

The Command will show its access information at the top, the URL to use to request in addition to the HTTP Verb.

Multilingual

Commands are available today with support for Typescript, Javascript, and Python languages. When adding a Node to a Command, the node-type needs to be selected. Once chosen, the entire node will utilize that language with its specific requirements. Any number of nodes can be combined together in a Command to implement any required logic and each node can be a different language.

In addition to code-based nodes, a SQL Node is available as well. This node is directly integrated into your Base and its corresponding database. No need to configure credentials or access keys, the SQL Node takes care of that for you and automatically will authenticate to your database.

Variables

During Command execution, all HTTP Request variables are available for access. In addition, each node’s output is available to any subsequent nodes.

Variables are referenced in Command nodes by using handlebar notation. For example, the querystring parameter named “id” would be referenced by: {{request.query.id}}.

HTTP Request Variables

Path params: Path params are defined in the Command by adding handlebar notation to the path (e.g. /workspace/{{id}}). Referenced as {{request.path.id}}.

{{ request.path.id}}

Query params: Querystring parameters on the request (e.g. ```/workspace?id=1234``` ) Referenced as: {{request.query.id}}

Body params: Request body parameters. Referenced as: {{request.body.id}}

Previous Nodes

Any output from a previous node is available also, allowing nodes to communicate with each other by taking inputs, performing any logic or operations on the data, then continuing on.

Node outputs are referenced through the Node Name whereas in the previous example were referenced as request. This allows unique names to be used and referenced accordingly.

Example

If a node named node-1 returned a JSON blob which had “id” in the object would be referenced as: {{node-1.id}}.

What’s Next

It’s notable what you can accomplish with Commands today, but still we have more ideas that we want to share with you.

Cron Commands

Current HTTP Triggers are great for on-demand requests, but many use-cases require them to be invoked on intervals. This is where a time-based trigger would be useful and is on the road map for Commands.

Additional Language Support

We’re looking to add additional languages in the future such as Rust, Golang, and .NET on top of the existing languages which provide even more options to author your Commands.

Command Marketplace

The marketplace is a centralized location that will allow users to use pre-built nodes in their Commands. Due to the composable architecture of Commands, nodes can be packaged and re-used by your team, or published and shared with anyone.