Meetily Tauri Command and Event Pattern: Frontend-Rust Communication Explained

Meetily implements Tauri's command-event pattern to enable bidirectional communication between its Next.js frontend and Rust backend, using invoke to trigger Rust commands and typed event listeners to receive real-time state updates.

Meetily is an open-source meeting assistant that leverages Tauri to combine a React/TypeScript frontend with a Rust-powered audio and transcription engine. The Tauri command and event pattern forms the crucial bridge between these layers, allowing the UI to trigger recording operations while receiving live transcript updates. This architecture maintains a clean separation of concerns: the Rust core holds authoritative state and manages system resources, while the frontend remains lightweight and reactive.

Command Pattern: Frontend to Rust Communication

The command pattern enables the Next.js frontend to invoke Rust functions asynchronously. This unidirectional flow initiates all heavy operations—including audio pipeline initialization and recording management—while awaiting results or errors.

Invoking Commands from TypeScript

The frontend uses Tauri’s invoke function to call annotated Rust functions. Arguments are passed as JSON-serializable objects, and the function returns a Promise that resolves with the command's return value or rejects with a Rust error.

import { invoke } from "@tauri-apps/api/tauri";

await invoke("start_recording", {
  mic_device_name: "Built‑in Microphone",
  system_device_name: "BlackHole 2ch",
  meeting_name: "Team Standup"
});

Defining Command Handlers in Rust

On the Rust side, commands are defined as async fn with the #[tauri::command] attribute. The AppHandle parameter provides access to the Tauri application context, enabling state management and event emission. In frontend/src-tauri/src/audio/recording_commands.rs, the start_recording command delegates to the audio subsystem after receiving device parameters from the frontend.

#[tauri::command]
async fn start_recording<R: Runtime>(
    app: AppHandle<R>,
    mic_device_name: Option<String>,
    system_device_name: Option<String>,
    meeting_name: Option<String>,
) -> Result<(), String> {
    // Delegate to the audio subsystem; return Ok on success
    audio::recording_commands::start(app, mic_device_name, system_device_name, meeting_name).await
}

Event Pattern: Rust to Frontend Communication

While commands handle frontend-initiated requests, events enable the Rust backend to push updates to the UI without polling. This is essential for real-time features like live transcription, where the backend processes audio chunks and immediately notifies the frontend of new text.

Emitting Events from Rust

The Rust side uses app.emit() to broadcast named events with typed payloads. This pattern appears throughout the audio processing pipeline, where the backend emits transcript-update events containing new transcription segments. The Manager trait from tauri::Manager brings the emit method into scope.

use tauri::Manager; // brings `emit` into scope

app.emit(
    "transcript-update",
    TranscriptUpdate {
        text: "Hello world".to_string(),
        timestamp: chrono::Utc::now(),
    },
)?;

Listening for Events in TypeScript

The frontend registers listeners using Tauri’s listen helper, specifying the event name and a callback that receives the typed payload. In frontend/src/components/Sidebar/SidebarProvider.tsx, the React context sets up listeners during component initialization to update local state when transcription data arrives.

import { listen } from "@tauri-apps/api/event";

await listen<TranscriptUpdate>("transcript-update", (event) => {
  // Append the new transcript chunk to the UI state
  setTranscripts((prev) => [...prev, event.payload]);
});

Complete Implementation Flow

The bidirectional pattern creates a stateless UI architecture where React components never maintain authoritative recording state. Instead, the flow follows this sequence:

1. User Action: The frontend in frontend/src/app/page.tsx calls invoke("start_recording", {...}) with device configuration
2. Rust Processing: The command handler in frontend/src-tauri/src/lib.rs routes to recording_commands.rs, which initializes the audio pipeline and begins capture
3. State Updates: As the audio processor generates transcripts, it emits transcript-update events via app.emit()
4. UI Rendering: The SidebarProvider receives the payload through its listen callback and updates React state, triggering a re-render with the new transcript chunk

This flow ensures that the Rust backend maintains the single source of truth for recording status and transcript data, while the frontend remains synchronized through event-driven updates.

Key Implementation Files

Several files work together to implement this pattern across the Meetily codebase:

• frontend/src-tauri/src/lib.rs – Registers all Tauri commands (e.g., start_recording) and provides the Rust-side entry point for the application
• frontend/src-tauri/src/audio/recording_commands.rs – Implements the command logic for audio operations and manages the recording state machine
• frontend/src/app/page.tsx – Contains the UI components that invoke commands and initialize the meeting interface
• frontend/src/components/Sidebar/SidebarProvider.tsx – Central React context that registers event listeners and distributes transcript data to child components
• CLAUDE.md – Documents the command-event pattern with concrete examples for both Rust and TypeScript implementations

Summary

• Bidirectional communication: Meetily uses invoke for frontend-to-Rust commands and emit/listen for Rust-to-frontend events
• Stateless UI: The React frontend does not hold authoritative recording state; it receives updates through typed events emitted by the Rust backend
• Type safety: Events use generic type parameters (listen<TranscriptUpdate>) to ensure payload integrity between Rust structs and TypeScript interfaces
• File organization: Commands are defined in recording_commands.rs and registered in lib.rs, while event consumption is centralized in React context providers

Frequently Asked Questions

What is the difference between Tauri commands and events?

Commands represent a request-response pattern initiated by the frontend using invoke, where the frontend waits for a Rust function to complete and return a value. Events represent a publish-subscribe pattern where the Rust backend pushes data to the frontend using emit, and any number of frontend listeners can receive updates via listen without having requested them. Meetily uses commands for user-initiated actions like starting recordings, and events for streaming transcript updates.

How does Meetily handle type safety between Rust and TypeScript?

Meetily leverages Tauri's ability to serialize Rust structs into JSON payloads that TypeScript can consume. When emitting events from Rust, the backend uses strongly-typed structs (e.g., TranscriptUpdate), and the frontend uses generic type parameters with listen<TranscriptUpdate> to ensure the payload matches the expected interface. This prevents runtime type mismatches during the command-event handshake.

Where are Tauri commands registered in the Meetily codebase?

Commands are registered in frontend/src-tauri/src/lib.rs using the .invoke_handler() method on the Tauri builder. This file maps string command names (like "start_recording") to their corresponding Rust function implementations, typically located in frontend/src-tauri/src/audio/recording_commands.rs. The registration happens during application initialization before the frontend window is created.

Can multiple frontend components listen to the same Rust event?

Yes, Tauri's event system supports multiple listeners for the same event name. In Meetily, the SidebarProvider and other components can independently register listeners for transcript-update events using listen(). Each callback receives the same payload independently, allowing different UI sections to react to the same backend update without coupling their state management logic.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}