DEV Community: Wess Cope

Stim: A Tiny Language for AI Prompts, Agents, and Workflows

Wess Cope — Mon, 29 Jun 2026 19:36:14 +0000

AI prompts are starting to look a lot like software.

Not just the quick one-off prompts we type into a chat box, but the reusable stuff.

The slash commands.

The agent definitions.

The rule files.

The system prompts.

The project-specific workflows.

The “please do this exact thing every time, in this exact order, with these exact constraints” files.

At some point, those stop feeling like notes.

They start feeling like source code.

So I built Stim.

Stim is a small DSL for writing AI prompts, commands, agents, and orchestration workflows as actual source files.

You write one .stim file, then compile it to the AI tool you want to use.

Claude Code today.

ChatGPT.

Cursor.

And hopefully more tools over time.

Repo:

https://github.com/wess/stim

The problem

Most AI workflow files are just Markdown.

And Markdown is great.

Until it isn’t.

A simple prompt is fine in Markdown:

You are a senior engineer.
Review this code for bugs.
Explain the most important issues first.

No problem there.

But then real workflows start creeping in.

You want the prompt to ask questions.

You want it to branch based on the answer.

You want reusable agents.

You want different output formats for different tools.

You want one version of the workflow that works in Claude Code, Cursor, or ChatGPT.

You want a review agent, a planning command, a security workflow, a writing assistant, and maybe a little team of agents that can work together.

Eventually the Markdown starts doing that thing where it is technically still Markdown, but spiritually it is a programming language wearing a fake mustache.

That is where Stim comes in.

What Stim is

Stim is a DSL for writing AI workflows.

It lets you define things like:

commands
agents
reusable orchestration harnesses
variables
imports
loops
conditionals
parallel tasks
fan-out and gather flows
package-based prompt libraries

Then Stim compiles those files into whatever your target tool expects.

For example:

stim install reviewer.stim

Can install a Claude Code agent.

stim install reviewer.stim --target cursor

Can compile the same source into a Cursor rule.

stim compile reviewer.stim --target chatgpt

Can create Markdown you can paste into ChatGPT or a Custom GPT.

That is the main idea:

Write the workflow once. Target the tool later.

A simple command

Here is a tiny Stim command:

command greet {
  ask("What's your name?")
  wait_for_response()
  ask("Nice to meet you! How can I help today?")
}

That can compile into a Claude Code slash command.

Nothing too wild.

But once commands become more involved, the structure starts to matter.

Here is a more useful example:

command brainstorm {
  ask("What problem are you trying to solve?")
  wait_for_response()

  done = false

  while (!done) {
    ask("What's the next important question we should answer?")
    wait_for_response()

    if (confirm("Does this feel complete enough to turn into a spec?")) {
      done = true
    }
  }

  create_file("SPEC.md", "Create a clear project spec from the conversation.")
}

That is the kind of thing I kept wanting.

Not just a prompt.

A workflow.

Something that can guide an AI tool through a repeatable process.

Agents are first-class too

Stim is not only for commands.

You can define agents:

agent security_reviewer {
  description "Reviews code for security vulnerabilities"
  tools [Read, Grep, Bash]
  model "sonnet"

  "You are a security engineer specializing in web application security."
  "Look for SQL injection, XSS, auth bypasses, exposed secrets, and unsafe deserialization."
  "Cite file paths and line numbers for every finding."
  "Prioritize findings by severity."
}

That can become a Claude Code agent.

Or it can compile to another target where some fields are handled differently.

For example, if a target does not support a field like tools or model, Stim can warn and drop that field instead of making you maintain a totally separate version.

That matters because every AI tool has its own format.

Claude Code wants one thing.

Cursor wants another thing.

ChatGPT wants something else.

Stim gives you a source format above those tools.

Commands, agents, and harnesses

Stim has three big building blocks.

Commands are interactive workflows:

command plan_feature {
  ask("What feature are we planning?")
  wait_for_response()
}

Agents are reusable personas with metadata:

agent doc_writer {
  description "Writes clear technical documentation"

  "You write documentation for engineers."
  "Use concrete examples from the actual code."
}

Harnesses are reusable orchestration templates:

harness find_verify {
  param finders
  param votes 3

  fanout over finders {
    task explore "investigate" {
      ask("Investigate this lead")
    }
  }

  gather "merge findings and remove duplicates"
}

That third one is important.

Stim is not just trying to make prettier prompt files.

It is trying to describe agentic workflows in a way that can be reused, shared, and compiled.

Multi-agent workflows

One of the things I’m most excited about is orchestration.

For example, you can describe a deeper review workflow like this:

command deep_review {
  ask("What code should I review?")
  wait_for_response()

  parallel {
    task explore "security scan" {
      ask("Check for SQL injection, XSS, auth flaws, and exposed secrets")
    }

    task explore "performance audit" {
      ask("Find N+1 queries, unnecessary allocations, and blocking I/O")
    }

    task explore "architecture review" {
      ask("Evaluate separation of concerns and dependency management")
    }
  }

  ask("Compile all findings into a single report")
  create_file("REVIEW.md", "review_report")
}

This is where Stim starts to feel different from just writing a prompt.

The file is describing a workflow shape.

Ask this.

Then run these tasks in parallel.

Then gather the result.

Then write the final output.

The AI tool still executes the workflow, but Stim gives you a cleaner way to define it.

Why this matters

I think prompt files are going to become more like code.

Maybe not all prompts.

A quick “explain this error” does not need a DSL.

But the prompts we reuse?

The prompts we commit to a repo?

The prompts that define how our agents behave?

The prompts that control team workflows?

Those deserve better tooling.

They should be parseable.

They should be validated.

They should be compiled.

They should be shared.

They should be versioned.

They should have packages.

They should have editor support.

They should eventually have tests.

That is the direction Stim is exploring.

Target different AI tools

Right now Stim supports multiple targets.

The idea is that a .stim file should be the source of truth, and each target adapter decides how to emit the final output.

For example:

stim install security_reviewer.stim

Installs for Claude by default.

stim install security_reviewer.stim --target cursor

Installs as a Cursor rule.

stim compile security_reviewer.stim --target chatgpt

Compiles to Markdown for ChatGPT.

This is one of the big reasons I wanted Stim to exist.

I do not want to rewrite the same agent or workflow three different ways just because every AI tool has a slightly different file format.

That gets old fast.

Package management

Stim also has a decentralized package idea.

Any GitHub repo with a stim.yaml manifest can become a package.

So you can install shared commands, agents, and workflows like this:

stim add github/wess/stim/packages/reviews
stim add github/wess/stim/packages/gitflow
stim add github/wess/stim/packages/planning
stim add github/wess/stim/packages/writing

That opens the door for reusable AI workflow libraries.

A team could have its own internal Stim package.

An open source project could publish review agents.

Someone could publish a whole set of planning, refactoring, testing, and documentation workflows.

That feels useful to me.

Not because every workflow should be installed from a package.

But because the good ones should be shareable.

Editor support

Stim also has an LSP.

That means editor integrations can share the same language server.

The repo includes plugin work for:

VS Code
Neovim
Zed

The goal is to make writing AI workflows feel more like writing code.

Syntax highlighting.

Diagnostics.

Snippets.

Compile commands.

Eventually, I want the experience to feel natural enough that editing a prompt workflow does not feel like editing a giant magic text blob.

Built with TypeScript and Bun

Stim is written in TypeScript and built with Bun.

To try it:

git clone https://github.com/wess/stim.git
cd stim
bun install
bun run build

Then:

./dist/stim version

You can compile a file:

stim compile examples/brainstorm.stim

Or install one:

stim install examples/reviewer.stim

There is also a token command:

stim tokens examples/deepreview.stim

That estimates the compiled token count, which is useful when workflows start getting bigger.

What I want Stim to become

The bigger idea is this:

AI workflows should not be locked inside one tool’s format.

I want to write the workflow once and take it with me.

I want to define a reviewer agent once.

I want to define a planning command once.

I want to define a multi-agent review process once.

Then I want to point it at Claude Code, ChatGPT, Cursor, or whatever tool comes next.

Tools will keep changing.

Prompt formats will keep changing.

Agent systems will keep changing.

But the workflow itself should be portable.

That is what Stim is aiming for.

A few things I’m excited to explore next

There is still a lot I want to improve.

Some ideas:

more target adapters
better package discovery
richer validation
stronger editor integrations
more first-party workflow packages
better examples
workflow testing
cleaner docs around advanced orchestration

I especially want to see what kinds of workflows other people would build with it.

Because everyone uses AI tools a little differently.

Some people want code review agents.

Some want planning systems.

Some want writing helpers.

Some want project-specific rule files.

Some want a small team of agents that can coordinate on a task.

Stim is meant to give those ideas a source format.

Try it out

Stim is early, but it is already useful enough that I wanted to share it.

You can check it out here:

https://github.com/wess/stim

If you are already building custom AI commands, agents, rules, or prompts, I would love for you to try it.

And if you have ideas, issues, or weird workflows you want to support, open an issue or send a PR.

I think we are still early in figuring out how developers should organize AI workflows.

Stim is my attempt at one answer:

Treat prompts like source code.

Then compile them wherever they need to go.

Been spending a lot of time building languages lately — Zeno, ZenoScript, and other experiments. A lot of parsing, transpiling, type systems, and thinking hard about ergonomics. All of that tinkering led me to Moxy: https://github.com/wess/moxy

Wess Cope — Fri, 20 Feb 2026 00:08:48 +0000

GitHub - moxylang/moxy: A superset for the almighty C language. · GitHub

A superset for the almighty C language. Contribute to moxylang/moxy development by creating an account on GitHub.

github.com

I Built a Server Library for Bun (and got carried away)

Wess Cope — Tue, 23 Dec 2025 19:32:12 +0000

I wanted a server library built for Bun, not ported from Node.js. Couldn't find one. So I built it.

What is Verb?

Express-style API, zero dependencies:

import { createServer } from "verb"

const app = createServer()

app.get("/", (req, res) => {
  res.json({ message: "Hello from Verb!" })
})

app.listen(3000)

One API, Many Protocols

HTTP, WebSocket, gRPC, TCP, UDP - same API:

import { server } from "verb"

const http = server.http()
http.get("/api/users", getUsers)

const ws = server.websocket()
ws.on("connection", handleConnection)

const grpc = server.grpc()
grpc.addService(userService, userHandlers)

Zero Dependencies

Verb uses only Bun's built-in APIs. No external packages. Clean node_modules, simple supply chain.

The Ecosystem

Then I needed more stuff. So I built that too:

Hull - Ecto-inspired database toolkit:

const User = schema("users")
  .uuid("id", { primaryKey: true })
  .string("email", 255)
  .timestamps()

const users = await all(repo, whereEq(from(User), "active", true))

Allow - Authentication (JWT, OAuth, local):

const allow = createAllow({
  secret: process.env.JWT_SECRET,
  strategies: [{ name: "local", type: "local", config: {} }]
})

app.get("/dashboard", requireAuth, dashboardHandler)

Hoist - Self-hosted deployment:

hoist deploy

Shelves - S3-compatible object storage you can self-host.

Getting Started

bunx @verb-js/create-verb my-app
cd my-app
bun run dev

Performance

~93k req/sec, ~0.5ms latency. Hybrid router with O(1) static lookups.

Links

MIT licensed. Questions? Drop them in the comments.

Realm: The Dev Environment That Eliminates Terminal Chaos

Wess Cope — Fri, 31 Oct 2025 15:49:43 +0000

I have been using this little tool for a bit because I don't always get to have docker in some of the specialized environments or platforms I build for. I decided to polish it up and release it.

The Problem: Development Environment Chaos

Modern full-stack development is surprisingly complex:

Multiple terminals: Frontend on port 3000, API on 4000, docs on 8080
Runtime management: Node 18 for one project, Node 20 for another
Proxy configuration: Manually configuring nginx or setting up CORS
Environment isolation: Global package pollution and version conflicts
Process orchestration: Remembering which services to start in which order

This complexity multiplies when you're working on multiple projects. Context switching becomes painful, and onboarding new developers means sharing a 50-step setup guide.

What is Realm?

Realm is a single CLI tool that replaces your entire development environment setup. It combines:

Virtualenv-like environments for complete project isolation
Built-in process manager (like Foreman) with intelligent routing
Multi-runtime support (Bun, Node.js, Python, Deno, Go)
Zero-config proxy server that routes requests to your services
Project templates to eliminate boilerplate
One-command deployment with Docker generation

All written in Rust for speed and reliability.

Installation

Getting started is simple:

# Using cargo
cargo install realmenv

# Or using the install script
curl -sSfL https://github.com/wess/realm/releases/latest/download/install.sh | bash

Pre-built binaries are available for macOS (Intel & Apple Silicon), Linux (x64 & ARM64), and Windows.

Quick Start: From Zero to Running in 30 Seconds

The interactive init experience makes setup effortless:

# Initialize with prompts
realm init

# Follow the prompts:
# → Project name: myapp
# → Select runtime: Bun (latest)
# → Use a template?: React + Express
# → Done!

cd myapp
source .venv/bin/activate
realm start

# Visit http://localhost:8000 - it just works!

That's it. No webpack config, no proxy setup, no port juggling. Everything runs on http://localhost:8000 with intelligent routing.

The Magic: How Realm Works

Realm acts as a single command center for your entire development environment:

┌─────────────────────────────────────────────┐
│ Realm CLI                                   │
├─────────────────────────────────────────────┤
│ Proxy Server (port 8000)                    │
│ ├── Route: /api/* → backend:4001            │
│ ├── Route: / → frontend:4000                │
│ └── Route: /health → built-in               │
├─────────────────────────────────────────────┤
│ Process Manager                             │
│ ├── frontend: bun run dev                   │
│ ├── backend: bun run server                 │
│ └── docs: bun run docs                      │
├─────────────────────────────────────────────┤
│ Runtime Manager                             │
│ ├── Bun 1.0.1 (per project)                 │
│ └── Node.js 20.5.0 (per project)            │
├─────────────────────────────────────────────┤
│ Environment Manager                         │
│ ├── .env file loading                       │
│ └── Variable isolation                      │
└─────────────────────────────────────────────┘

1. Smart Proxy Routing

Instead of manually configuring nginx or dealing with CORS issues, Realm's built-in proxy handles everything:

# realm.yml
proxy_port: 8000

processes:
  frontend:
    command: "bun run dev"
    port: 4000
    routes: ["/", "/assets/*"]

  backend:
    command: "bun run server"
    port: 4001
    routes: ["/api/*", "/health"]

The proxy automatically:

Routes requests based on URL patterns
Handles WebSocket connections (for HMR, live reload)
Adds CORS headers for development
Provides health checks

2. Process Management

Like Foreman or Overmind, but integrated with routing:

realm start  # Start everything
realm stop   # Stop everything

All process output is aggregated with colored prefixes, so you can see what's happening across your entire stack.

3. Runtime Isolation

Similar to virtualenv for Python or nvm for Node, but project-scoped:

# Use latest Bun
realm init myapp --runtime=bun

# Use specific Node.js version
realm init myapp --runtime=node@20

# Use Python with complete isolation
realm init myapp --runtime=python@3.12

Runtimes are downloaded and cached per-project. No more global version conflicts!

Built-in Templates

Realm includes templates for common full-stack patterns:

react-express: React + Express (Bun/Node)
react-fastapi: React + FastAPI (Python)
svelte-fastify: SvelteKit + Fastify
vue-express: Vue 3 + Express
nextjs: Next.js 14 full-stack app

# Create from template
realm init myapp --template=react-fastapi --runtime=python@3.12

cd myapp
source .venv/bin/activate
pip install -r backend/requirements.txt
realm start

You can also create your own templates with custom variables:

# template.yaml
name: my-stack
description: My custom template

variables:
  - name: project_name
    prompt: "Project name"
    default: "{{directory_name}}"

  - name: api_port
    prompt: "API port"
    default: "3001"

Production: One Command to Deploy

When you're ready to deploy, Realm generates production-ready Docker artifacts:

realm bundle

This creates a dist/ folder with:

Dockerfile: Multi-stage build for all processes
docker-compose.yml: Complete service orchestration
nginx.conf: Reverse proxy with your routing rules
deploy.sh: One-command deployment script

No more wrestling with Docker or deployment configurations.

Real-World Comparison

The Old Way 🔥

# Terminal 1
cd frontend && npm run dev

# Terminal 2
cd backend && npm run server

# Terminal 3
nginx -c nginx.conf

# Terminal 4
export NODE_ENV=development
export API_URL=http://localhost:4001
source .env

# Remember all ports, manage processes manually...

The Realm Way ✨

realm init myapp --template=react-express
source .venv/bin/activate
realm start

# Everything runs on http://localhost:8000

When Should You Use Realm?

Realm shines when you're:

Building full-stack applications with separate frontend/backend
Working on multiple projects that need different runtime versions
Onboarding developers and want a simple setup experience
Tired of managing terminals and proxy configurations
Want fast deployment without Docker expertise

Community Runtimes

Beyond the built-in support for Bun, Node, and Python, Realm supports custom runtimes through YAML configuration:

# Add Deno support
curl -o ~/.realm/runtimes-config/deno.yaml \
  https://raw.githubusercontent.com/wess/realm/main/runtimes/deno.yaml

realm init --runtime=deno

# Add Go support
curl -o ~/.realm/runtimes-config/go.yaml \
  https://raw.githubusercontent.com/wess/realm/main/runtimes/go.yaml

realm init --runtime=go

Check out the community runtimes for more options.

Under the Hood

Realm is built in Rust with a modular architecture:

CLI layer: Command-line interface with clap
Config parsing: YAML configuration with serde
Runtime management: Version downloads and caching
Process management: Lifecycle orchestration
Proxy server: HTTP routing with tokio
Template engine: Tera-based scaffolding
Bundle generator: Docker artifact creation

The entire tool is focused on developer experience: fast startup, clear error messages, and zero configuration when possible.

Feature Comparison

Feature	Realm	Docker Compose	Foreman	Create-React-App
Process Management	✅	✅	✅	❌
Built-in Proxy	✅	❌	❌	❌
Runtime Isolation	✅	✅	❌	❌
Project Templates	✅	❌	❌	✅
Production Deploy	✅	✅	❌	✅
Zero Config	✅	❌	❌	✅
Multi-Runtime	✅	✅	❌	❌

Realm combines the best aspects of these tools into a cohesive development environment.

Getting Started

Ready to simplify your development workflow?

Install Realm: cargo install realmenv
Initialize a project: realm init
Start developing: realm start

Check out the GitHub repository for documentation, examples, and to contribute.

Conclusion

Modern full-stack development doesn't have to be complex. With Realm, you get:

One command to start your entire stack
Automatic routing without proxy configuration
Runtime isolation without global pollution
Templates to eliminate boilerplate
Deployment generation without Docker expertise

If you've ever felt frustrated managing multiple terminals, runtime versions, or proxy configurations, give Realm a try. It might just change how you approach development environments.

Have you tried Realm? What's your biggest pain point in full-stack development? Let me know in the comments!

Links:

Verb :: Fast Everything Server

Wess Cope — Wed, 09 Jul 2025 15:11:49 +0000

A fast, modern server framework for Bun with multi-protocol support. Build HTTP, HTTP/2, WebSocket, gRPC, UDP, and TCP servers with the same intuitive API.

https://github.com/wess/verb

Verb is designed specifically for the Bun run time, for more information on Bun checkout https://bun.sh

Features

Multi-Protocol Support - HTTP, HTTP/2, WebSocket, gRPC, UDP, TCP
Unified API - Same interface across all protocols
Runtime Protocol Switching - Switch between protocols dynamically
Built for Bun - Native Bun APIs for maximum performance
TypeScript First - Full type safety out of the box

Install / Add

# Install dependencies
bun add github:wess/verb

Basic Usage:

HTTP Server

import { createServer } from "verb";

const app = createServer();

app.get("/", (req, res) => {
  res.json({ message: "Hello World!" });
});

app.listen(3000);

Protocol Selection

import { createServer, ServerProtocol } from "verb";

// HTTP/2 server
const http2Server = createServer(ServerProtocol.HTTP2);

// WebSocket server
const wsServer = createServer(ServerProtocol.WEBSOCKET);
wsServer.websocket({
  open: (ws) => ws.send("Connected!"),
  message: (ws, message) => ws.send(`Echo: ${message}`)
});

// gRPC server
const grpcServer = createServer(ServerProtocol.GRPC);
grpcServer.addMethod("UserService", {
  name: "GetUser",
  handler: async (request) => ({ id: request.id, name: "John" })
});

// UDP server
const udpServer = createServer(ServerProtocol.UDP);
udpServer.onMessage((message) => {
  console.log("UDP:", message.data.toString());
});

// TCP server
const tcpServer = createServer(ServerProtocol.TCP);
tcpServer.onConnection((connection) => {
  connection.write("Welcome to TCP server!");
});

Fluent API

import { server } from "verb";

const httpApp = server.http();
const grpcApp = server.grpc();
const udpApp = server.udp();

Protocol Gateway

Switch between protocols at runtime with the same routes:

import { ProtocolGateway, ServerProtocol } from "verb";

const gateway = new ProtocolGateway();

// Define routes that work across HTTP-based protocols
gateway.defineRoutes((app) => {
  app.get("/api/status", (req, res) => {
    res.json({ 
      status: "healthy",
      protocol: gateway.getCurrentProtocol() 
    });
  });
});

// Start with HTTP
gateway.listen(3000);

// Switch to HTTP/2
gateway.switchProtocol(ServerProtocol.HTTP2);
gateway.listen(3001);

// Switch to WebSocket
const wsServer = gateway.switchProtocol(ServerProtocol.WEBSOCKET);
wsServer.websocket({
  open: (ws) => ws.send("WebSocket ready!")
});
gateway.listen(3002);

Available Protocols

Protocol	Enum	Description
HTTP/1.1	`ServerProtocol.HTTP`	Standard HTTP server
HTTP/2	`ServerProtocol.HTTP2`	HTTP/2 with multiplexing
WebSocket	`ServerProtocol.WEBSOCKET`	WebSocket with HTTP routes
gRPC	`ServerProtocol.GRPC`	gRPC service definitions
UDP	`ServerProtocol.UDP`	UDP message handling
TCP	`ServerProtocol.TCP`	TCP connection management

API Reference

HTTP-based Servers (HTTP, HTTP/2, WebSocket)

// Route methods
app.get(path, handler)
app.post(path, handler)
app.put(path, handler)
app.delete(path, handler)
app.patch(path, handler)

// Middleware
app.use(middleware)

// Start server
app.listen(port, hostname?)

WebSocket Server

app.websocket({
  open: (ws) => { /* connection opened */ },
  message: (ws, message) => { /* message received */ },
  close: (ws) => { /* connection closed */ }
});

gRPC Server

app.addService(service)
app.addMethod(serviceName, method)

UDP Server

app.onMessage((message) => { /* handle message */ })
app.send(data, port, address)

TCP Server

app.onConnection((connection) => { /* handle connection */ })
app.onData((connection, data) => { /* handle data */ })

Development

# Run tests
bun test

# Lint code
bun run lint

# Format code
bun run format

Introducing Zenoscript

Wess Cope — Fri, 27 Jun 2025 20:57:35 +0000

Have you ever wished TypeScript felt more functional? Meet Zenoscript — a new language built with the power of functional programming and the practicality of the TypeScript ecosystem. It compiles directly to TypeScript, meaning there's zero runtime overhead and complete interoperability with existing TS codebases.

🚀 What Is Zenoscript?

Zenoscript is a functional-first programming language that compiles to clean, idiomatic TypeScript. It’s built for developers who want features like pattern matching, structural typing, and immutable data structures—without giving up access to TypeScript libraries or tools.

Highlights:

✅ Functional by default — immutable, pure functions, expressive patterns
⚡️ Zero runtime dependencies — compiles to plain TS
🔁 Seamless TypeScript interop
🔧 Modern DX — CLI, REPL, VS Code extension
🧪 Built for Bun — fast, lightweight, dev-friendly

🧠 Core Features

🎭 Pattern Matching with Atoms

let handleResponse = match response {
  :success(data) => processData(data)
  :error(msg) => logError(msg)
  :loading => showSpinner()
  _ => defaultHandler()
}

🔗 Pipe Operator

Zenoscript makes chaining transformations readable and elegant:

let activeUsers = users
  |> filter(user => user.status === :active)
  |> map(user => user.name)
  |> sort

🧱 Structural Typing with Traits

struct User {
  id: number;
  name: string;
  email: string;
  status: UserStatus;
}

trait Serializable {
  serialize(): string;
  deserialize(data: string): Self;
}

🛡 Immutable by Default

let numbers = [1, 2, 3]
let doubled = numbers |> map(x => x * 2)
// numbers stays unchanged, doubled = [2, 4, 6]

✨ Why Use Zenoscript?

No runtime bloat
Your code compiles straight to efficient TypeScript.
Use TS libraries
Import .zs files directly into Bun + TypeScript projects:

  import { User } from "./types.zs"
  import { processData } from "./handlers.zs"

Great Dev Experience
- Live REPL (zeno repl)
- VS Code plugin
- Helpful errors
- Hot reloading

📦 Getting Started

🛠 Installation

# macOS / Linux
curl -fsSL https://zeno.run/install.sh | bash

# Windows (PowerShell)
iwr https://zeno.run/install.ps1 | iex

# Or via Bun
bun install -g zenoscript

🧪 Your First Project

mkdir my-app && cd my-app
zeno init
bun dev

You’ll get a ready-to-run dev setup with hot reloading.

🧾 Basic Example

// user.zs

struct User {
  name: string;
  email: string;
  status: Symbol;
}

let users = [
  { name: "Alice", email: "alice@example.com", status: :active },
  { name: "Bob", email: "bob@example.com", status: :inactive }
]

let getActiveUsers = () => users
  |> filter(user => user.status === :active)
  |> map(user => user.name)

let statusMessage = (status) => match status {
  :active => "User is currently active"
  :inactive => "User is inactive"
  _ => "Unknown status"
}

console.log("Active users:", getActiveUsers())

🔮 What’s Next for Zenoscript?

✨ Guard clauses in pattern matching
🧠 Smarter type inference and compile-time checks
📚 Expanded standard lib with functional utilities
🛠 Debug tooling + improved IDE support
🕸 WebAssembly compilation targets

💡 Contribute & Explore

Zenoscript is open-source and welcoming contributors:

GitHub: wess/zenoscript
VS Code Extension: Available on the releases page
Docs & Examples: Explore tutorials and example apps

Ready to Try It?

curl -fsSL https://zeno.run/install.sh | bash
zeno init my-app && cd my-app
bun dev

Then explore the language and share what you build! ✨

Let me know what you think of Zenoscript in the comments below. Are you ready to go functional without leaving the TypeScript universe?

✍️ Originally published on zeno.run/blog
🏗 Project site: https://zeno.run

Verb: A Fast, Zero-Dependency HTTP Framework for Bun

Wess Cope — Tue, 03 Jun 2025 00:10:32 +0000

There's a new HTTP framework in the Bun ecosystem that's worth checking out: Verb. It takes a refreshingly simple approach - leveraging Bun's built-in capabilities instead of reinventing the wheel.

What Makes Verb Interesting

Verb is built directly on Bun's native HTTP server with zero external dependencies. This means you get the raw performance of Bun without any abstraction overhead. Here's the simplest example:

import { createServer, json, text } from "verb";

const app = createServer({ port: 3000 });

app.get("/", () => text("Hello, Verb!"));
app.get("/api/users/:id", (req, params) => json({ id: params.id }));

That's a working server. No configuration files, no boilerplate.

Key Features

Intelligent Route Caching

Verb uses an LRU cache for compiled route patterns. After the first request to a route, subsequent matches are nearly instant:

// These patterns are compiled once, then cached
app.get("/users/:id", handler);
app.get("/posts/:userId/comments/:commentId", handler);
app.get("/static/*", handler); // Including wildcards

Built-in Streaming Support

Streaming is first-class in Verb, making it straightforward to handle real-time data, large exports, or progressive loading:

// Server-Sent Events
app.get("/events", () => {
  async function* eventGenerator() {
    let count = 0;
    while (count < 100) {
      yield {
        data: JSON.stringify({ count, timestamp: Date.now() }),
        event: "update"
      };
      await new Promise(r => setTimeout(r, 1000));
      count++;
    }
  }
  return streamSSE(eventGenerator());
});

// Stream large JSON datasets as JSONL
app.get("/api/export", () => {
  async function* dataGenerator() {
    for (let i = 0; i < 100000; i++) {
      yield { id: i, data: `Record ${i}` };
    }
  }
  return streamJSON(dataGenerator());
});

Middleware System

The middleware API is straightforward and composable:

// Request timing
app.use(async (req, next) => {
  const start = Date.now();
  const response = await next();
  console.log(`${req.method} ${req.url} took ${Date.now() - start}ms`);
  return response;
});

// Built-in compression
app.use(compression());

// Simple auth check
app.use(async (req, next) => {
  if (req.url.startsWith("/api/") && !req.headers.get("authorization")) {
    return error("Unauthorized", 401);
  }
  return next();
});

HTTP/2 Support

Full HTTP/2 support with server push capabilities:

const app = createServer({
  http2: true,
  tls: { cert: "./cert.pem", key: "./key.pem" }
});

// Push critical resources with the response
app.get("/", () => {
  return responseWithPush(
    htmlContent,
    [
      { path: "/styles/critical.css", type: "text/css" },
      { path: "/js/app.js", type: "application/javascript" }
    ]
  );
});

Testing Utilities

Verb includes a mock server for testing without network overhead:

import { createMockServer } from "verb";
import { expect, test } from "bun:test";

test("user endpoint returns correct data", async () => {
  const app = createMockServer();
  app.get("/users/:id", (req, params) => json({ id: params.id }));

  const response = await app.request.get("/users/123");
  const data = await response.json();
  expect(data).toEqual({ id: "123" });
});

Complete Example: REST API

Here's a full CRUD API to show how these pieces fit together:

import { createServer, json, parseBody, error } from "verb";

const app = createServer({ port: 3000 });

// In-memory store
const users = new Map();
let nextId = 1;

// Enable compression
app.use(compression());

// List users
app.get("/api/users", () => {
  return json(Array.from(users.values()));
});

// Get specific user
app.get("/api/users/:id", (req, params) => {
  const user = users.get(parseInt(params.id));
  if (!user) return error("User not found", 404);
  return json(user);
});

// Create user
app.post("/api/users", async (req) => {
  const body = await parseBody(req);
  const user = { id: nextId++, ...body };
  users.set(user.id, user);
  return json(user, 201);
});

// Update user
app.put("/api/users/:id", async (req, params) => {
  const id = parseInt(params.id);
  if (!users.has(id)) return error("User not found", 404);

  const body = await parseBody(req);
  const user = { id, ...body };
  users.set(id, user);
  return json(user);
});

// Delete user
app.delete("/api/users/:id", (req, params) => {
  const id = parseInt(params.id);
  if (!users.delete(id)) return error("User not found", 404);
  return new Response(null, { status: 204 });
});

Static File Serving

Verb handles static files with caching, ETags, and compression:

// Serve files from ./public
app.get("/static/*", serveStatic({
  root: "./public",
  maxAge: 86400,      // 1 day cache
  immutable: true,    // Add immutable directive
  etag: true,         // Generate ETags
  extensions: [".html"] // Try .html if not found
}));

// Simpler syntax for basic use cases
app.get("/assets/*", staticFiles("./assets"));

Performance Considerations

Since Verb is built directly on Bun's HTTP server:

No additional parsing or routing layers
Route caching eliminates regex compilation on hot paths
Native HTTP/2 and TLS support
Minimal memory allocations per request

The framework is particularly well-suited for:

High-throughput APIs
Real-time applications using SSE or WebSockets
Services that need to stream large amounts of data
Microservices where startup time and memory usage matter

Installation and Usage

# Install from GitHub
bun add github:wess/verb

# Create a simple server
echo 'import { createServer, text } from "verb";
const app = createServer({ port: 3000 });
app.get("/", () => text("Hello from Verb!"));' > server.ts

# Run it
bun server.ts

When to Use Verb

Verb is a good fit if you're:

Already using Bun or planning to migrate
Building APIs or microservices
Need streaming capabilities
Want minimal dependencies
Prioritizing performance

It might not be the right choice if you:

Need to run on Node.js
Want a full-stack framework with templating, ORM, etc.
Prefer convention-over-configuration frameworks

Wrapping Up

Verb demonstrates what's possible when you build specifically for Bun's strengths. By avoiding unnecessary abstractions and leveraging native capabilities, it delivers both performance and a clean API.

The project is actively maintained and open to contributions. Check out the GitHub repository for more examples, documentation, and to get involved.

If you're exploring Bun for your next project, Verb is definitely worth a look. It's one of those tools that does one thing really well - serving HTTP requests fast.

Have you tried Verb or other Bun frameworks? What's been your experience? Share your thoughts in the comments.

Purge: Uninstaller for macOS That Goes Deep

Wess Cope — Mon, 19 May 2025 12:35:53 +0000

Purge: A CLI Uninstaller for macOS That Goes Deep

Dragging apps to the trash on macOS leaves behind preferences, caches, and support files that waste space and can cause conflicts. purge (or prg) is a command-line tool that finds and removes all these hidden files.

Key Features

Smart Detection: Extracts app identifiers from Info.plist files
Thorough Scanning: Searches all standard macOS system locations
Interactive Selection: Choose which files to keep or delete
Self-Contained: Single binary with no runtime dependencies
Coming Soon: Dry-run mode to preview without deleting

Installation

# Via Homebrew
brew tap wess/packages
brew install purge

# Or manually
git clone https://github.com/wess/purge.git
cd purge
npm install
npm run build:mac
ln -sf "$(pwd)/dist/prg-macos-$(uname -m)" /usr/local/bin/prg

Latest releases can also be downloaded at https://github.com/wess/purge (throw a star!)

Usage

prg /Applications/SomeApp.app

An interactive checklist appears with all related files. Uncheck items to keep, press Enter to trash the rest.

Options:

-n, --dry-run: Preview files without deleting (coming soon)
-h, --help: Show help information

How It Works

Reads the app's metadata to find identifiers
Scans system folders where apps store their data
Matches files based on naming patterns
Displays all candidates for your review before deleting

Why Use Purge?

Clean System: Recover space from hidden caches and support files
Prevent Conflicts: Avoid issues when reinstalling applications
Terminal Efficiency: Perfect for command-line workflows and scripts
Complete Control: See exactly what's being removed

Join the Community

purge is open-source on GitHub. Issues, feature suggestions, and pull requests are welcome!

What leftover app files are hiding on your Mac? Try purge and let us know what you discover!

Rove : Straight up PostgreSQL migration.

Wess Cope — Fri, 16 May 2025 17:01:35 +0000

Rove is a fast, no-fluff migration manager for PostgreSQL built with Bun and TypeScript. It’s built for devs who just want to write raw SQL, version it in folders, and run it with confidence.

No ORMs. No DSLs. Just SQL.

Install

Install it using Homebrew:

brew install wess/packages/rove

Or clone it and run directly with Bun:

bun install
bun run rove migrate

How It Works

Migrations live in a migrations/ folder. Each migration is a directory with an incrementing number prefix and two files: up.sql and down.sql.

migrations/
├── 001_create_users/
│   ├── up.sql
│   └── down.sql
├── 002_add_index/
│   ├── up.sql
│   └── down.sql

To run migrations:

rove migrate

To roll back the most recent one:

rove rollback

Rove tracks what's been applied in a migrations table in your database. It uses the DATABASE_URL (or POSTGRES_URL) environment variable to connect.

Commands

Here’s the full list of supported commands:

rove init            # Initialize the migrations/ folder
rove new <name>      # Generate a new numbered migration
rove create          # Create the database
rove drop            # Drop the database
rove up              # Create DB if needed + run pending migrations
rove migrate         # Run any pending migrations
rove rollback        # Roll back the most recent migration
rove down            # Alias for rollback
rove status          # Show which migrations have been applied
rove dump [file]     # Dump current schema (default: schema.sql)
rove load [file]     # Load schema from file (default: schema.sql)

You can also run:

rove --help

to get usage info at any time.

Why Rove?

Most migration tools make you jump through hoops, invent YAML-based formats, or force you into their ORM. Rove does exactly one thing: it runs your SQL migrations.

✅ Built with Bun for speed
✅ Uses raw SQL, no wrappers
✅ Fast and scriptable for CI/CD
✅ Easy to version-control
✅ No global state or weird config files

Whether you're starting fresh or just want something small and sharp to replace heavier tools, Rove is a solid fit.

Getting Started

rove init
rove new create_users
# edit up.sql / down.sql
rove migrate

Need to reset the database?

rove drop && rove create && rove migrate

Want to snapshot the current schema?

rove dump

Final Thoughts

If you want your migrations to be transparent, versionable, and fast, Rove delivers. Built for Bun but works with anything that talks to PostgreSQL.

👉 github.com/wess/rove

Feedback, issues, and contributions always welcome.

Appwrite Etsy OAuth Integration

Wess Cope — Wed, 05 Oct 2022 15:06:46 +0000

Appwrite 1.0 is out now! We have released some amazing features, and also added a few more OAuth2 providers, one of which is Etsy. Let’s go ahead and learn how to set up Etsy authentication in our applications using Appwrite.

About Appwrite

Appwrite is a self-hosted backend-as-a-service platform that provides developers with all the core APIs required to build any application. Appwrite provides you with a set of APIs, tools, and a management console UI to help you build your apps a lot faster and in a much more secure way.

📃Prerequisites

To follow along with this tutorial, you’ll need access to an Appwrite project or permissions to create one. If you don’t already have an Appwrite server running, follow the official installation tutorial to set one up. Once you create a project on the Appwrite Console, you can head over to Users →Settings to find the list of all supported OAuth2 providers. This is where we will set up the Etsy OAuth provider.

You will also need an account at Etsy, so if you don’t have one, you can easily create one for free from here.

🔐 Configure Etsy OAuth

Once our Appwrite project is up and running, we must create an app at Etsy. After signing in, head over to https://www.etsy.com/developers/register and create a new application.

🤝Enable Etsy in Appwrite

To enable Etsy in Appwrite, visit the Appwrite Dashboard and head over to Users→Settings.
From the list of providers, choose Etsy and enter the App ID and App Secret from the previous step (i.e., the Client Id and Client Secret).

Make sure you copy the redirect URL from Appwrite’s Etsy OAuth Setting dialog and paste it to your Etsy app’s Callback URL.

Follow the Getting Started for Web guide for detailed instruction on how to use Appwrite with your web application.

Import {Client, Account} from ‘appwrite’;

const client = newClient();

appwrite
  .setEndpoint('[YOUR_END_POINT]')
  .setProject('[YOUR_PROJECT_ID]');

    await appwrite.account.createOAuth2Session(
        "Etsy",
        "[YOUR_END_POINT]/auth/oauth2/success",
        "[YOUR_END_POINT]/auth/oauth2/failure",
    );

const account = new Account(client);
account.createOAuth2Session();

Flutter

For Flutter, in Android, to properly handle redirecting your users back to your mobile application after completion of the OAuth flow, you need to set the following in your AndroidManifest.xml file.

<manifest ...>
  ...
  <application ...>
    ...
    <!-- Add this inside the `<application>` tag, along side the existing `<activity>` tags -->
    <activity android:name="com.linusu.flutter_web_auth.CallbackActivity" android:exported="true">
      <intent-filter android:label="flutter_web_auth">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="appwrite-callback-[PROJECT_ID]" />
      </intent-filter>
    </activity>
  </application>
</manifest>

You also need to add the Flutter platform to your project from the Appwrite console. Adding Flutter platforms allows Appwrite to validate the request it receives and prevents requests from unknown applications. On the project settings page, click on Add Platform button and select New Flutter App. In the dialog box that appears, select the appropriate Flutter platform, give a recognizable name to your platform and add the application ID or package name based on the platform. You need to follow this step for each Flutter platform you will build your application for.

For more detailed instructions on getting started with Appwrite for Flutter developers, follow our official Getting Started for Flutter guide. Finally, you can call account.createOAuth2Session from your application as shown below.

import 'package:appwrite/appwrite.dart';

void main() async {
    final client = new Client();

    client
    .setEndpoint('YOUR_END_POINT')
    .setProject('YOUR_PROJECT_ID');

    final account = Account(client);

    try {
        await account.createOAuth2Session(
            provider: "Etsy"
        );
    } catch (error) {
        throw error;
    }
}

Android

For Android, to properly handle redirecting your users back to your mobile application after completion of the OAuth flow, you need to set the following in your AndroidManifest.xml file.

<manifest ...>
  ...
  <application ...>
    ...
    <!-- Add this inside the `<application>` tag, along side the existing `<activity>` tags -->
    <activity android:name="io.appwrite.views.CallbackActivity" android:exported="true">
      <intent-filter android:label="android_web_auth">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="appwrite-callback-[PROJECT_ID]" />
      </intent-filter>
    </activity>
  </application>
</manifest>

You also need to add the Android platform to your project from the Appwrite console. Adding Android platforms allows Appwrite to validate the request it receives and also prevents requests from unknown applications. On the project settings page, click on Add Platform button and select New Android App. In the dialog box that appears, give your platform a recognizable name and add the package name of your application.

For more detailed instructions on getting started with Appwrite for Android developers, follow our official Getting Started for Android guide. Finally, you can call account.createOAuth2Session from your application as shown below.

import androidx.appcompat.app.AppCompatActivity
import android.os.Bundle
import kotlinx.coroutines.GlobalScope
import kotlinx.coroutines.launch
import io.appwrite.Client
import io.appwrite.services.Account

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val client = Client(applicationContext)
            .setEndpoint("https://[HOSTNAME_OR_IP]/v1") // Your API Endpoint
            .setProject("5df5acd0d48c2") // Your project ID

        val account = Account(client)

        GlobalScope.launch {
            account.createOAuth2Session(
                activity = this@MainActivity,
                provider = "Etsy"
            )

        }
    }
}

Apple

To capture the Appwrite OAuth callback URL, the following URL scheme needs to add to your Info.plist.

<key>CFBundleURLTypes</key>
<array>
<dict>
    <key>CFBundleTypeRole</key>
    <string>Editor</string>
    <key>CFBundleURLName</key>
    <string>io.appwrite</string>
    <key>CFBundleURLSchemes</key>
    <array>
        <string>appwrite-callback-[PROJECT_ID]</string>
    </array>
</dict>
</array>

For more detailed instructions on getting started with Appwrite for iOS developers, follow our official Getting Started for Apple guide. Finally, you can call account.createOAuth2Session from your application as shown below.

import Appwrite

let client = Client()
    .setEndpoint("[YOUR_ENDPOINT]")
    .setProject("[YOUR_PROJECT_ID]")

let account = Account(client)

account.createOAuth2Session(
    provider: "Etsy"
){ result in
    switch result {
    case .failure(let err):
        print(err.message)
    case .success:
        print("logged in")
    }
}

Conclusion

Well, that’s all it takes to set up Etsy OAuth-based authentication with Appwrite. The following resources can be handy if you want to explore Appwrite further.

Almost Netflix: A Netflix clone built with Flutter + Appwrite

Wess Cope — Fri, 21 Jan 2022 11:20:22 +0000

Welcome to the third post in our Almost Netflix series! We'll be building upon the project setup from yesterday and build a frontend for our Netflix Clone! In this post, we will take a closer look at building the clone using Flutter. In the subsequent posts of this series, we'll be building frontends for other platforms like iOS and Android!

This one's all about Flutter, so let's get started!

It would be impossible to write every piece of code in this article 😬 You will read about all essential concepts, components, and communication with Appwrite. Still, if you want to check out every corner of our Almost Netflix in Flutter, you can check out the GitHub Source Code that holds the whole application.

🤔 What is Appwrite?
Appwrite is an open source backend-as-a-service that abstracts all the complexity involved in building a modern application by providing you with a set of REST APIs for your core backend needs. Appwrite handles user authentication and authorization, databases, file storage, cloud functions, webhooks, and much more! If anything is missing, you can extend Appwrite using your favorite backend language.

To run the project, checkout the source code and then $ flutter run and be sure to check out the screenshots:

📃 Requirements

Before we begin, we should have the Appwrite instance up and running, with the Almost Netflix project set up. Please follow our article about Almost Netflix project setup if you don't have a project prepared yet.

To build Almost Netflix we will be using Flutter along with a couple of libraries to help out.

To make things a bit easier to use and more reusable, we are going to use provider library instead of InheritedWidget, including simplified resource management, reduced boilerplate, lazy loading and a nice listening mechanism to go with ChangeNotifier

To manage the user's preferences, location and credentials storage (across platform) we are going to lean on the shared_preferences library that will give us simplified persistent storage for simple data (NSUserDefaults on iOS/macOS, SharedPreferences on Android, etc.). To handle pop-ups and modals we are going to use adaptive_dialog for presenting our detail views as modals. For the pretty UI we are going to use as much "batteries included" UI (default is Material) as we can.

That's it, and if you are unfamiliar with these libraries or Flutter in general, please take some time to go read up! Never stop learning!

🛠️ Create Flutter Project

If you do not have Flutter installed yet, please head over to Flutter install.

With Flutter installed, let's create our application. On the command line, simply run: $ flutter create --platform=ios,android --org=io.appwrite /path/to/almost_netflix. This command will create the app using the flag --platform to tell Flutter who you are targeting and --org for your company/personal identifier (usually it's a reverse url style deal). With our project created, let's open up that folder in our favorite editor.

In our project open up the file pubspec.yaml and lets add a few things, starting with our dependencies (mentioned above) first. Look for dependencies: and under it, let's add our libraries. Once you have added them, the dependencies section should look like:




dependencies:
  Flutter:
    sdk: Flutter


  # The following adds the Cupertino Icons font to your application.
  # Use with the CupertinoIcons class for iOS style icons.
  cupertino_icons: ^1.0.2
  provider: ^6.0.1
  fluro: ^2.0.3
  appwrite: ^3.0.1
  shared_preferences: ^2.0.11

  # Any of your other dependencies too

The last item to take care of is our assets. We are going to create a new directory in our project called assets and then download (save) all our assets from the static folder on GitHub into our newly created assets folder. Now let's jump back into our pubspec.yaml file, and scroll till you see the section assets: and let's add our assets folder path so it looks like:



# ...

Flutter:

  # The following line ensures that the Material Icons font is
  # included with your application, so that you can use the icons in
  # the Material Icons class.
  uses-material-design: true

  assets:
    - images/

#... contd.

Great, the project is ready! Now let's get Appwrite in here.

🤖 Appwrite Client

We are going to create lib/api/client.dart and write a simple singleton and some shortcuts for talking with our Appwrite backend.



// libs/api/client.dart

import 'package:appwrite/appwrite.dart';

class ApiClient {
  Client get _client {
    Client client = Client();

    client
    .setEndpoint('https://your.appwrite.url/v1')
    .setProject('yourNetflixClone')
    .setSelfSigned();

    return client;
  }

  static Account get account => Account(_instance._client);
  static Database get database => Database(_instance._client);
  static Storage get storage => Storage(_instance._client);

  static final ApiClient _instance = ApiClient._internal();
  ApiClient._internal();
  factory ApiClient() => _instance;
}

With our client in place we can now create AccountProvider that will manage the state and method calls for our user's account, such as sign-up and sign-in. All providers will be classes that extend ChangeNotifier



import 'dart:convert';
import 'package:Flutter/material.dart';
import 'package:appwrite/models.dart';
import 'package:shared_preferences/shared_preferences.dart';
import 'package:almostNetflix2/api/client.dart';

class AccountProvider extends ChangeNotifier {
  User? _current;
  User? get current => _current;

  Session? _session;
  Session? get session => _session;

  Future<Session?> get _cachedSession async {
    final prefs = await SharedPreferences.getInstance();
    final cached = cached.get("cached.session");

    if(cached == null) {
      return null;
    }

    return Session.fromMap(json.decode(cached));
  }

  Future<bool> isValid() async {
    if (session == null) {
      final cached = await _cachedSession;

      if (cached == null) {
        return false;
      }

      _session = cached;
    }

    return _session != null;
  }

  Future<void> register(String email, String password, String? name) async {
    try {
      final result = await ApiClient.account.create(
        userId: 'unique()',
        email: email, 
        password: password, 
        name: name
      );

      _current = result;

      notifyListeners();
    } catch(_e) {
      throw Exception("Failed to register");
    }
  }

  Future<void> login(String email, String password) async {
    try {
      final result = await ApiClient.account.createSession(email: email, password: password);
      _session = result;

      final prefs = await SharedPreferences.getInstance();
      prefs.set("cached.session", json.encode(result.toMap()));

      notifyListeners();
    } catch(e) {
      _session = null;
    }
  }
}

Now that we have our provider, and our little nice provider methods for our account, we need to tell the app we want to use providers, so let's head over to main.dart and make it "Provider Aware" updating it to the following:



// main.dart

import 'package:appflix/providers/account.dart';
import 'package:Flutter/material.dart';
import 'package:provider/provider.dart';

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();

  runApp(
    MultiProvider(
      providers: [
        ChangeNotifierProvider(create: (context) => AccountProvider()),
      ],
      child: Main(),
    )
  );
}

class Main extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Appflix',
      theme: ThemeData(
        scaffoldBackgroundColor: Colors.black,
        primarySwatch: Colors.blue,
        visualDensity: VisualDensity.adaptivePlatformDensity,
      ),
      home: FutureBuilder(
        future: context.read<AccountProvider>().isValid(),
        builder: (context, snapshot) => Container(
          child: Text("Main")
        ),
      )
    );
  }
}

🔐 Authentication

For authentication we are going to create 2 forms for our onboarding screen. You can see the completed widget here: onboarding.dart. Be sure to grab it and add it into your project. On both forms you will see that the submit buttons have onPressed events. With our provider we can use this event to sign-in or sign-up a user:



  onPressed: () async {
    final api = context.read<AccountProvider>();
    final name = _nameController.text;
    final email = _emailController.text;
    final password = _passwordController.text;

    if (email.isEmpty || password.isEmpty) {
      showDialog(context: context, builder: (_) => AlertDialog(
        title: const Text('Error'),
        content: const Text('Please enter your email and password'),
        actions: [
          TextButton(
            child: const Text('OK'),
            onPressed: () => Navigator.of(context).pop(),
          )
        ],
      ));

      return;
    }

    await api.register(email, password, name);

  },



onPressed: () async {
  final api = context.read<AccountProvider>();
  final email = _emailController.text;
  final password = _passwordController.text;

  if (email.isEmpty || password.isEmpty) {
    showDialog(context: context, builder: (_) => AlertDialog(
      title: const Text('Error'),
      content: const Text('Please enter your email and password'),
      actions: [
        TextButton(
          child: const Text('OK'),
          onPressed: () => Navigator.of(context).pop(),
        )
      ],
    ));

    return;
  }

  await api.login(email, password);

},

The sign-in/sign-up events take the entered email and password and then call their associated functions on AccountProvider that we added earlier, once complete our provider will notify everyone who is watching for a valid user to show up. So let's head back over to main.dart and make a quick adjustment to react when a user is present.

Update main.dart to:



class Main extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Appflix',
      theme: ThemeData(
        scaffoldBackgroundColor: Colors.black,
        primarySwatch: Colors.blue,
        visualDensity: VisualDensity.adaptivePlatformDensity,
      ),
      home: FutureBuilder(
        future: context.read<AccountProvider>().isValid(),
        builder: (context, snapshot) => context.watch<AccountProvider>().session == null ? const OnboardingScreen() : const Container(child: Text("HOME")),
      )
    );
  }
}

🎬 Movies page

Once our user is authenticated we will need to load up the movies page that will show a featured movie followed by a couple of lists of movies. For this we will create our EntryProvider that will give us access to our Appwrite database of movies. So we are going to create 2 files: lib/data/entry.dart and lib/providers/entry.dart

First lib/data/entry.dart will be our Data model for our Movie data stored in Appwrite's database.



class Entry {
  final String id;
  final String name;
  final String? description;
  final String ageRestriction;
  final Duration durationMinutes;
  final String thumbnailImageId;
  final String genres;
  final String tags;
  final DateTime? netflixReleaseDate;
  final DateTime? releaseDate;
  final double trendingIndex;
  final bool isOriginal;
  final String cast;

//... cont'd
}

Second our lib/providers/entry.dart



class EntryProvider extends ChangeNotifier {

  static String _collectionId = "movies";

  Entry _featured = Entry.empty();
  Entry get featured => _featured;

  List<Entry> _entries = [];
  List<Entry> get entries => _entries;

  List<Entry> get originals => _entries.where((entry) => entry.isOriginal).toList();

  List<Entry> get trending {
    var trending = _entries;

    trending.sort((a, b) => b.trendingIndex.compareTo(a.trendingIndex));

    return trending;
  }

  Future<void> list() async {
    var result = await ApiClient.database.listDocuments(collectionId: _collectionId);

    _entries = result.documents.map((document) => Entry.fromJson(document.data)).toList();
    _featured = _entries.isEmpty ? Entry.empty() : _entries[0];

    notifyListeners();
  }

  Future<Uint8List> imageFor(Entry entry) async {
    return await ApiClient.storage.getFileView(fileId: entry.thumbnailImageId);
  }
}

Then we create our homepage, which you can view at lib/screens/home.dart and attach our provider. Here we tell our widget to watch the featured property of our provider, if it changes the view will redraw for the updated property.

Watch Featured



slivers: [
  SliverToBoxAdapter(
    child: ContentHeader(featured: context.watch<EntryProvider>().featured),
  ),

Next we tell our home widget to also watch the list in the provider to provide data to display in our lists.

Watch all entries



SliverToBoxAdapter(
  child: ContentList(
    title: 'Mylist',
    contentList: context.watch<EntryProvider>().entries,
    isOriginal: false,
  ),
),

With that our app will now show a list view with several sub-lists which are segmented into categories.

🕵️ Detail page

With our lists in place, we want a user to be able to tap a movie and get a modal to give more detail about the movie selected. On user select we are going to tell our provider that we have a selected entry, so let's add the following to our lib/providers/entry.dart



Entry? _selected;
Entry? get selected => selected;

Future<void> select(Entry? entry) async {
  _selected = entry;

  notifyListeners();
}

And now we need to create a new view called lib/screens/details.dart to display our selected entry as well as update lib/widgets/content/list.dart to present a modal of our movie's detail view.

Let's update list.dart to use adaptive_dialog and present our details view for the selected movie.

Show the Modal



onTap: () {
  await showDialog(
    context: context, 
    builder: (context) => const DetailsScreen(entry: current),
  );
},

Now we need to update lib/screens/details.dart to allow the selected entry (movie) to be passed in.



class DetailsScreen extends StatefulWidget {
  final Entry _entry;

  DetailsScreen({Key? key, required Entry entry}) : _entry = entry, super(key: key);

So now when a user taps a movie in the list, they will be presented with a detail view for their selection.

🔖 Watchlist page

We want our user to be able to list, add and remove movies from their own watchlist, so to do this we will create another provider lib/providers/watchlist.dart that will handle our api calls and also communicating to the UI the data and actions. So we need to tell the app that we want to use our WatchlistProvider by adding it to our lib/main.dart like we did with the others:



Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();

  runApp(
    MultiProvider(
      providers: [
        ChangeNotifierProvider(create: (context) => AccountProvider()),
        ChangeNotifierProvider(create: (context) => EntryProvider()),
        ChangeNotifierProvider(create: (context) => WatchListProvider()),
      ],
      child: Main(),
    )
  );
}

When our user selects "My List" we will present a list of movies saved to the watchlist, with an option to delete it.

In libs/widgets/content/bar.dart we are going to add an action to the _AppBarButton

Show Watchlist



_AppBarButton('My List', () async {
  await showDialog(
    context: context, 
    builder: (context) => const WatchlistScreen()
  );
}),

Now when the user adds a movie to their watchlist, they can come here to see or delete it.

For our users to add a movie to their list, we call the add method on the WatchlistProvider and once added we dismiss the detail view.

Add to Watchlist



 tap: () {
  context.read<WatchListProvider>().add(widget._entry);
  Navigator.pop(context);
}

And to delete a movie from our list, we add a call to our remove method on our WatchlistProvider.

Remove from Watchlist



tap: () {

  context.read<WatchListProvider>().remove(entry);

}

👨‍🎓 Conclusion

And with that, we have cloned (Almost) Netflix with nothing more than some frontend magic, and Appwrite as our backend! To become part of the Appwrite community, you can join our Discord server. I look forward to seeing what you build and who you are (when you join our discord!)

Now for the post credits scene: We have more to do, we have more to show, so as Appwrite releases, our Netflix clone will grow so get ready for anything, from streaming to dreaming! 😉

🔗 Learn more

You can use the following resources to learn more and get help regarding Appwrite and its services