How Meetily Uses Tauri Commands to Connect Frontend and Rust Backend

Meetily bridges its Next.js frontend and Rust backend through Tauri commands, where JavaScript calls invoke to trigger #[tauri::command] annotated Rust functions, while Rust pushes real-time updates to the UI via asynchronous events.

Meetily is an open-source meeting transcription desktop application built with Next.js and React for the UI and Rust with Tauri for the backend engine. The communication between the thin React presentation layer and the performance-critical Rust audio processing logic relies entirely on Tauri commands for request-response operations and Tauri events for server-pushed updates.

Defining Commands in Rust with #[tauri::command]

In Meetily's codebase, every callable backend function is defined as an async Rust function decorated with the #[tauri::command] attribute. These functions accept the AppHandle (or Window) and serialized arguments from the frontend, returning Result<T, String> to ensure type-safe error handling.

The concrete implementations for audio operations reside in src-tauri/src/audio/recording_commands.rs, where functions like start_recording receive device parameters and meeting metadata before delegating to the audio pipeline:

#[tauri::command]
pub 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 recording manager
    audio::recording_commands::start(
        &app,
        mic_device_name,
        system_device_name,
        meeting_name,
    )
    .await
    .map_err(|e| e.to_string())
}

Registering Commands in the Tauri Builder

Before the frontend can invoke Rust logic, commands must be explicitly registered in the Tauri application builder. In src-tauri/src/lib.rs, the invoke_handler macro is populated with tauri::generate_handler!, which lists all available commands. This registration step exposes the Rust functions to the JavaScript runtime, creating the secure bridge between the WebView frontend and the native backend.

Invoking Commands from the Next.js Frontend

The frontend uses the invoke helper from @tauri-apps/api/tauri to call registered commands by name, passing a plain object of arguments that Tauri serializes automatically. This pattern allows React components to remain thin, delegating heavy lifting—such as initiating audio capture with specific microphone and system device names—to the Rust backend while awaiting Promise-based responses:

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

// Start a meeting recording
async function startRecording(meetingName: string) {
  const result = await invoke<null>('start_recording', {
    micDeviceName: 'Built‑in Microphone',
    systemDeviceName: 'BlackHole 2ch',
    meetingName,
  });

  if (result instanceof Error) {
    console.error('Failed to start recording:', result);
  }
}

Pushing Updates with Tauri Events (Rust to Frontend)

For asynchronous updates that originate in Rust—such as incoming transcript chunks from the Whisper engine or recording state changes—the backend uses the app.emit method on the AppHandle to broadcast events. The frontend registers listeners using listen from @tauri-apps/api/event, receiving typed payloads that update React state without polling.

Rust side emitting an event:

use tauri::Manager;

// After a transcript chunk is received:
app.emit(
    "transcript-update",
    TranscriptUpdate {
        text: chunk_text,
        timestamp: chrono::Utc::now(),
    },
)?;

Frontend side listening for the event:

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

listen<TranscriptUpdate>('transcript-update', (event) => {
  setTranscripts((prev) => [...prev, event.payload]);
});

This event-driven architecture ensures the UI remains responsive during long-running transcription tasks.

Key Files in the Tauri Command Architecture

Meetily's command pattern spans several core files that handle distinct responsibilities:

• src-tauri/src/lib.rs: Registers all commands via invoke_handler and tauri::generate_handler!, plus bootstraps the Tauri application.
• src-tauri/src/audio/recording_commands.rs: Implements command handlers for start_recording, stop_recording, and related audio operations.
• src-tauri/src/state.rs: Manages shared application state accessible to both commands and event emitters.
• src-tauri/src/audio/pipeline.rs: Contains the core audio mixing and voice activity detection (VAD) logic invoked by recording commands.
• src-tauri/src/whisper_engine/whisper_engine.rs: Handles Whisper model loading and speech-to-text transcription results passed back to the frontend.

Summary

• Tauri commands in Meetily provide a type-safe RPC mechanism between Next.js and Rust using #[tauri::command] and invoke.
• Commands are registered centrally in src-tauri/src/lib.rs via generate_handler! and invoke_handler.
• The frontend uses invoke from @tauri-apps/api to call Rust functions with serialized arguments and await results.
• Rust pushes real-time updates to the frontend through app.emit, consumed by frontend listeners using listen.
• Heavy processing tasks remain isolated in Rust while the React UI handles only presentation logic.

Frequently Asked Questions

How does Meetily handle errors in Tauri commands?

Meetily commands return Result<T, String> from Rust, where errors are converted to strings via map_err. The frontend receives these as rejected Promises, allowing TypeScript catch blocks to handle failures from operations like failed audio device initialization.

Can Tauri commands in Meetily access shared state?

Yes. Commands receive the AppHandle parameter, which provides access to the application state managed in src-tauri/src/state.rs. This allows commands like start_recording to update shared recording status that event emitters later read when broadcasting updates to the frontend.

What is the difference between Tauri commands and events in Meetily?

Commands follow a request-response pattern where the frontend calls invoke and awaits a result from a specific #[tauri::command] function. Events follow a publish-subscribe pattern where Rust calls app.emit to broadcast updates and the frontend listens asynchronously, making events suitable for streaming transcript chunks or status updates.

Where are the Whisper transcription commands implemented?

The Whisper engine integration resides in src-tauri/src/whisper_engine/whisper_engine.rs, which provides the transcription logic called by recording commands. When audio processing completes, results flow back to the frontend either through command responses or via transcript-update events emitted during real-time transcription.

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