Picos as the database

Picos can be used as the database layer of a web application. In fact, the pico developer UI is such a web application. So is our Manifold project^* at Pico Labs. Both of these feature a front end running in the browser (written using the ReactJS framework (and so are single page applications^**)).

Typically when using databases, an application program retrieves the data from a row into memory, thus bringing the data to the code. With picos, we bring the code to the data, by installing rulesets in each entity pico.

Database shards

Each pico represents one entity. As such, it corresponds to a row of a relational database table, or to a document in a document database collection.

When using picos in this way, we have what we could call a fully sharded table, with each row being represented by a single virtual machine, its pico. The pico contains the data itself (in entity variables) and also any code that is needed to handle/manage/present that data (as rulesets).

Databases are typically horizontally partitioned for performance reasons. Taking this to the limit, each shard contains only a single row.

This concept is the subject of the first half (the second half of the title) of a slide show, "Credential-based login to Pico-based application". This can be thought of as a further step in the move from monolithic applications to a microservice architecture^***. The movement is towards a service oriented architecture, and what we are proposing here could be called an entity oriented architecture.

Entity oriented web applications

In such an architecture, each entity has its own service. Both the code and the data are together in one place, providing the service.

Advantages

Locality: each entity can be located where it makes the most sense. For example, a pico representing a person could be hosted in Ireland for someone in Europe, in Moscow for someone in Russia, in Virginia for someone in the Americas, etc.

Ownership: each entity can be controlled by the person who owns it. A pico representing a manufactured item could be owned in succession by the manufacturer, the wholesaler, the retailer, the purchaser, and so forth. Multiple ownership is also supported, with for example, a manufacturer continuing to have certain access (with purchaser approval) to the pico throughout the lifecycle of the item.

Versatility: each entity can have different capabilities, depending on the rulesets installed in it. This happens now in Manifold, where each owned thing has the same base rulesets, but an owner can add additional features to their thing, increasing and diversifying its capabilities.

Disadvantages

Aggregation, reporting across a collection of similar entities, can be more difficult than when using a traditional database.

With each entity serviced by a separate virtual machine, more care has to be taken to deal with network failures and server downtime.

Persistence

Picos are persistent, with their state surviving across server cycling. So, of course, there must be data storage somewhere other than the memory of a running instance.

Each pico is hosted by a pico engine which stores its entity variable values in a database. A pico engine can host many picos, and runs as a web server.

As needed, a given pico begins its existence on a pico engine, but during its lifetime can move to another pico engine when that becomes necessary or desirable.

The bottom line is that there is a database, but it is not something that the developer of KRL code has to be concerned about.

Notes

^* Manifold is a web application that owners of things can use to keep track of those things. Each owned thing is represented by a pico, and each owner is represented by a pico as well.

^** In a previous post, the author disparaged single page applications (SPA), but they do of course have their place. Using picos as the database layer of a SPA makes a lot of sense, and the two web applications mentioned comprise a proof of concept.

^*** Taking the metric prefix "micro" to mean six orders of magnitude smaller, we might use the sister prefix "pico" and characterize the architecture proposed in this post as a "picoservice architecture".