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.

(or at least that's the goal...)

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

Getting Started

Install the Rust and WebAssembly components.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

rustup target add wasm32-wasip1 wasm32-unknown-unknown

Next, install the ordinary CLI.

cargo install ordinary

Build the example project.

ordinary build ./ordinary.so

Run the example standalone.

ordinary preview ./ordinary.so

Run The Example Project in a Container

Build the image.

docker build -t ordinaryd .

Run the image (after ordinary build ./ordinary.so).

docker run -p 8080:80 -v ./ordinary.so:/ordinaryd/project:ro ordinaryd

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).

Structure

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

| admin console 💻
    | auth 🔒
    | template 📄
    | interface for: daemon 🌐
    
## applications
| app 🕸️
    | templates 📄
    | assets 🖼️
    | content 🔤
    | monitors 📊
    | auth 🔒
    | storage 💾
        | streams 🎥
        | notifications 📢
    | actions 🎬
    | integrations 🔗
    | serves one: app client 📱
    | runs on one or a cluster of many: daemon(s) 🌐

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

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.

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.

Presentation

Templates

Templates process the results of storage/content queries and transform them such that they present a useful view to the consumer (HTML, TXT, XML, CSV, JSON, etc.).

Templates can be configured to be processed on the server or the client or used to generate static sites.

Themes

Plain ol' CSS.

Components

Catalogs of Web Components...

Static

Content

...

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.

Identity

Accounts

...

Security

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

Interaction

Actions

Officially supported languages:

• Rust
• JavaScript

At there core Actions are custom WebAssembly modules that can be used to define new functionality and extend the underlying capabilities of the application.

Ergonomic bindings are generated for Rust and JavaScript. Other languages such as C/C++, Zig, Go, Kotlin, C#, etc. can also be compiled to WASM but this project doesn't generate ergonomic bindings for those languages, yet.

Models

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

...

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.

Integrations

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

Observability

...

Publish All

cargo publish -p notatype --allow-dirty
cargo publish -p configinator --allow-dirty
cargo publish -p scramblr --allow-dirty
cargo publish -p certifiably --allow-dirty
cargo publish -p cbwaw --allow-dirty
cargo publish -p gobetween --allow-dirty
cargo publish -p hammertime --allow-dirty
cargo publish -p stewball --allow-dirty
cargo publish -p startmeup --allow-dirty
cargo publish -p stencilr --allow-dirty
cargo publish -p skyhook --allow-dirty
cargo publish -p godfather --allow-dirty
cargo publish -p itsalive --allow-dirty
cargo publish -p moar --allow-dirty
cargo publish -p ordinaryd --allow-dirty
cargo publish -p ordinary --allow-dirty