The WordPress of Desktop applications without its quirks
Building modern desktop applications has always been a balancing act between development velocity, performance, and extensibility. When I started working on Orbis, I had a clear vision: what if we could combine the raw performance of Rust with the rich ecosystem of React, while making plugin development accessible to developers who don't want to ship frontend code?
The result is Orbis—a plugin-driven desktop application platform that redefines how we think about extensibility.
The Problem with Traditional Plugin Systems
If you've ever developed plugins for tools like VS Code, IntelliJ, or Figma, you know the pain:
- You're shipping code in an unfamiliar environment: Every platform has its own APIs, quirks, and limitations.
- UI is hard: You either get limited UI primitives or have to learn yet another framework.
- Security is an afterthought: Most plugin systems trust plugin code implicitly.
- State management becomes spaghetti: Coordinating between plugin state and host application state is a nightmare.
I wanted to solve all of these problems. And I wanted to do it without trading on application performance, so the answer is Rust.
Introducing Orbis
Orbis is built on a radical idea: plugins don't ship React code, they ship JSON schemas.
{
"type": "Container",
"children": [
{
"type": "Heading",
"level": 1,
"text": "Hello, {{state.username}}!"
},
{
"type": "Button",
"label": "Count: {{state.clicks}}",
"events": {
"onClick": [
{
"type": "updateState",
"path": "clicks",
"value": "{{state.clicks + 1}}"
}
]
}
}
]
}
That's it. No JSX, no bundlers, no framework lock-in. The Orbis core interprets this schema and renders production-ready React components using shadcn/ui.
Why Schema-Driven UI?
1. Security by Design
When plugins can't ship arbitrary JavaScript, they can't run arbitrary JavaScript. Every interaction goes through a controlled action system. Want to make an API call? Use the call_api action. Want to navigate? Use the navigate action. The core validates every action before execution.
2. Consistency
Every plugin looks and feels native. No more jarring UI mismatches where one plugin uses Material Design and another uses Bootstrap. Everything renders through the same component library.
3. Simplicity
You don't need to be a frontend developer to create a plugin. If you can write JSON (or eventually, our custom DSL), you can build a UI.
The Architecture
Orbis uses a layered architecture with clear separation of concerns:
┌─────────────────────────────────────────────────┐
│ User Interface │
│ (Plugin Pages & UI) │
├─────────────────────────────────────────────────┤
│ Frontend Layer │
│ Schema Renderer │ Zustand State │ Actions │
├─────────────────────────────────────────────────┤
│ Backend Layer │
│ Tauri Commands │ Plugin Runtime │ Auth │
├─────────────────────────────────────────────────┤
│ Plugin System │
│ WASM Sandbox │ Manifests │ UI Schemas │
├─────────────────────────────────────────────────┤
│ Storage Layer │
│ SQLite │ PostgreSQL │
└─────────────────────────────────────────────────┘
The Frontend: React + Zustand + Immer
The frontend is built with React and uses Zustand for state management. But here's the key insight: each plugin page gets its own isolated state store.
// Simplified: each page has isolated state
const pageStore = createPageStateStore({
username: "Guest",
clicks: 0
});
No global state pollution. No cross-plugin conflicts. Just a clean, isolated state.
The Backend: Rust + Tauri + Axum
The backend is pure Rust, built on Tauri for the desktop wrapper and Axum for the HTTP server. This gives us:
- Native performance: No Electron bloat
- Memory safety: Rust's guarantees extend to our plugins
- Cross-platform: Windows, macOS, Linux from a single codebase
The Plugin Runtime: WASM Sandboxing
Here's where it gets interesting. Plugins are compiled to WASM and run in wasmtime sandboxes. This means:
- Plugins can't access the filesystem without permission
- Plugins can't make network requests without permission
- Plugins can't crash the host application
- Plugins run in isolated memory spaces
You control your application and environments, not plugins.
35+ UI Components, 16 Action Types
Out of the box, Orbis provides:
- Layout Components
- Form Components
- Display Components
- Interactive Components
- And more
Each component maps to a well-tested shadcn/ui implementation. You get accessibility, keyboard navigation, and modern UI patterns for free.
The Action System
Actions are how plugins interact with the world:
{
"type": "call_api",
"api": "users.list",
"method": "GET",
"onSuccess": [
{
"type": "update_state",
"path": "users",
"value": "{{$response.body.data}}"
}
]
}
Available actions include:
-
update_state: Modify page state -
call_api: Make HTTP requests -
navigate: Navigate between routes -
show_toast: Display toast notifications -
show_dialog/close_dialog: Handle modals -
validate_form/reset_form: Manage form states -
conditional: If/else logic - And more...
Two Deployment Modes
Standalone Mode
Perfect for single-user desktop applications. Uses embedded SQLite for storage. Zero external dependencies.
Client-Server Mode
For multi-user applications. Connect to a central Orbis server with PostgreSQL backend. Full authentication, session management, and more.
Security First
Security isn't bolted on—it's baked in. You get by default:
- Secure authentication: JWT tokens with Argon2 password hashing
- Session Management: Secure session handling with refresh tokens
- WASM Sandboxing: Plugins run in isolated environments
- TLS Support: Optional HTTPS with rustls (no OpenSSL or other system dependencies)
What's Coming Next
The roadmap is ambitious:
- Plugin Marketplace: Discover and install plugins with one click
- Inter-Plugin Communication: Secure message passing between plugins
- Custom DSL: A cleaner syntax than JSON for page definitions
- Full GUI Override: Let plugins completely replace the default UI
- Auto-Updates: Tauri's built-in updater for seamless updates
- Check out the full roadmap for upcoming features
Getting Started
# Clone the repository
git clone https://github.com/cyberpath-HQ/orbis
cd orbis
# Install frontend dependencies
cd orbis && bun install
# Run in development mode
bun run tauri dev
Your first plugin can be as simple as:
{
"name": "hello-world",
"version": "0.1.0",
"pages": [
{
"id": "main",
"title": "Hello World",
"route": "/hello",
"state": {
"message": { "type": "string", "default": "Hello, Orbis!" }
},
"layout": {
"type": "Container",
"children": [
{
"type": "Heading",
"text": "{{state.message}}"
}
]
}
}
]
}
Why Rust?
The choice of Rust wasn't arbitrary. Beyond the performance benefits, Rust's ownership model ensures:
- No data races in our plugin runtime
- Predictable memory usage
- Fearless concurrency for plugin execution
- Compile-time guarantees that would be runtime errors elsewhere
Plus, the Rust ecosystem for WASM is mature. Wasmtime gives us a battle-tested sandbox, Tauri gives us a lean desktop wrapper, and Axum gives us a fast async HTTP server.
Conclusion
Orbis represents a new approach to extensible desktop applications. By separating the what (JSON schemas) from the how (React rendering), we've created a platform where:
- Plugin developers focus on functionality, not framework quirks
- Users get consistent, secure, beautiful applications
- The core team can evolve the rendering layer without breaking plugins
If you're building a desktop application that needs to be extended—whether it's an internal tool, a developer utility, or a full product—give Orbis a try.
🔗 Links
- Website: orbis.cyberpath-hq.com
- GitHub: github.com/cyberpath-HQ/orbis
- Documentation: orbis.cyberpath-hq.com/docs
- Issues & Discussions: GitHub Issues
If you found this interesting, follow for more deep dives into Rust, security, and developer tooling. And if you build something with Orbis, I'd love to see it!
Top comments (0)