Ordinary

A web server, deployment environment, load balancer, reverse proxy, auth provider, CMS, asset manager, content cache, relational database, ORM, edge runtime, and observability platform, all rolled into one.

"Build, measure, learn" with an intuitive design studio, developer CLI, and anonymized application insights.

Getting Started

First install the Rust and WebAssembly components.

## install Rust
curl https://sh.rustup.rs -sSf | sh

## add WebAssembly targets
rustup target add wasm32-wasip1 wasm32-unknown-unknown

Now you can install the ordinary CLI.

## install CLI
cargo install ordinary

Structure

## infrastructure
| deployment server 🌐
    | auth 🔒
    | monitors 📊
    | hosts many: apps 🕸️
    | serves one: admin console 💻

| admin console 💻
    | auth 🔒
    | template 📄
    | interacts with one: deployment server 🌐
    
## applications
| app 🕸️
    | auth 🔒
    | assets 🖼️
    | storage 💾
        | streams 🎥
        | notifications 📢
    | content 🔤
    | actions 🎬
    | integrations 🔗
    | templates 📄
    | monitors 📊
    | serves one: app client 📱
    | runs on one or many: deployment servers 🌐

| app client 📱
    | auth 🔒
    | flags 🚩
    | themes 🎨
    | templates 📄
    | obfuscation 🔐
    | interacts with one: app 🕸️

Studio & CLI

The studio is still very WIP but in its end state should be a one-stop shop for designers, developers and product experts to collaborate on the creation of Ordinary Web Experiences.

All levels of project development should be able to be preformed from the Ordinary Studio, but this is not mandatory, as all underlying config and project files are in familiar formats which can be engaged with via your typical development workflows (i.e your fav terminal and text editor).

All commands that the Ordinary Studio executes behind the scenes are available as commands for the ordinary CLI (also very WIP and needs to be properly documented).

Admin

Many apps on a single node; single app across many nodes.

The admin process facilitates the running of multiple apps on a single node, and peer connections to app instances on other nodes. It is started on a host machine and then exposes commands via an HTTP server.

This is also referred to as the "deployment server" or "deployment environment."

Apps

The app module contains the mechanisms for auth, storage, template processing, request proxying and action invocation.

An app typically corresponds to one or more domains/subdomains, and runs as an HTTP server. Each app runs on a dedicated thread in the deployment environment.

Themes

Themes are sets of JavaScript files (web components) and CSS files whose components/rules can be individually selected for inclusion.

Clients

The clients for each application are served from the app server as a WebAssembly module. Inside the client module are all of the instructions for rendering your application-specific templates.

Flags

Feature flags are dictated by the server and set for clients so that a changes to the application can be tested in smaller batch sizes before being rolled out to all users. Flags can be correlated to monitors to provide better insights into the impact of your changes.

Auth

Password based authentication is supported for users, and permissions/access-controls are token claim based.

Storage

The storage engine is a lightweight graph store (built with LMDB) designed for efficient querying/caching in the web application context. Compression, encryption and caching controls are configurable at the item and field levels.

Streams

...

Notifications

...

Templates

Templates process the results of storage queries, plugin executions, and proxy responses to transform them such that they present a useful view to the consumer (HTML, CSS, JSON, etc.).

Templates can be configured to be processed on the server or the client (static pages can also be configured to be pre-processed so they're only evaluated at build time).

Actions

At there core Actions are custom WebAssembly modules that can be used to define new functionality and extend the underlying capabilities of the application. Actions can be written in Rust, C++, C, Zig, Go, Kotlin, C# and any other language that can be compiled to WebAssembly.

Integrations

Integrations are designed to stand between a client, and web requests to 3rd party services. These proxies allow REST/gRPC/GraphQL requests to be defined as config, and parsed back into the compact template-consumable format.

Monitoring

Application monitoring is event/behavior oriented, meaning that each time a user or application triggers a behavior that has been configured to be tracked, it is recorded as an event that can be observed by the application developer or admin.

Obfuscation

Obfuscation allows you to configure fields or entire models to be sent and stored in such a way that they are opaque to the host/application owner. It is the intention to support libsignal and rgp for this purpose.