# Main Components of the Meetily Architecture: Frontend, Rust Core, and LLM Layers

> Explore the Meetily architecture: Next.js/React frontend, Rust core for audio/transcription, and LLM layers for summarization, all powered by Tauri. Discover its components.

- Repository: [Zackriya Solutions/meetily](https://github.com/Zackriya-Solutions/meetily)
- Tags: architecture
- Published: 2026-07-27

---

**Meetily combines a Next.js and React frontend, a Rust backend core that handles audio capture and local transcription, and optional external LLM services for summarization, all bound together by Tauri commands and events.**

Meetily, from the Zackriya-Solutions/meetily repository, is an open-source meeting assistant built with a **privacy-first**, offline-capable design. The main components of the Meetily architecture divide into three logical layers that communicate through **Tauri** commands and events. Understanding these layers is essential for developers who want to customize the audio pipeline, extend the UI, or plug in new summarization providers.

## Meetily Frontend Architecture: Next.js and React UI

The user-facing layer is a **Next.js** and **React** web view rendered inside a Tauri window. It manages all interactions—including starting recordings, displaying live transcripts, and browsing meeting history—without processing audio directly. Key files include [`frontend/src/app/page.tsx`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src/app/page.tsx) for the main recording interface, [`frontend/src/components/Sidebar/SidebarProvider.tsx`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src/components/Sidebar/SidebarProvider.tsx) for global React state, and [`frontend/src-tauri/src/utils.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/utils.rs) for UI helper utilities.

The frontend drives the Rust backend by invoking Tauri commands and listening for real-time events. To start a capture session, the UI calls the `start_recording_with_devices_and_meeting` command registered in [`frontend/src-tauri/src/lib.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/lib.rs):

```typescript
// frontend/src/app/page.tsx (simplified)
await invoke('start_recording_with_devices_and_meeting', {
  mic_device_name: selectedMic,
  system_device_name: selectedSystem,
  meeting_name: currentMeeting,
});

```

Live transcripts stream to the UI through the `transcript-update` event. The frontend subscribes via Tauri’s `listen` API and appends chunks to React state as they arrive:

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

await listen<{
  text: string;
  timestamp: number;
}>('transcript-update', event => {
  setTranscript(prev => [...prev, { ...event.payload }]);
});

```

For device selection, the UI fetches available hardware through the `get_audio_devices` command:

```typescript
const devices = await invoke<AudioDevice[]>('get_audio_devices');

```

## Meetily Backend Architecture: Rust Core and Command Registry

The Rust backend is the heart of the application and lives entirely under `frontend/src-tauri/src/`. It exposes functionality to the UI via `#[tauri::command]` functions and manages audio capture, speech-to-text, summary generation, persistence, and system integration.

### Application Bootstrap in [`lib.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/lib.rs)

The entry point is [`frontend/src-tauri/src/lib.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/lib.rs). Its `run()` function constructs the Tauri application, registers every command, initializes the system tray, and starts the Whisper engine, Parakeet engine, and builtin-AI summary sidecar:

```rust
// frontend/src-tauri/src/lib.rs
builder
    .plugin(tauri_plugin_notification::init())
    .manage(whisper_engine::parallel_commands::ParallelProcessorState::new())
    .setup(|_app| { /* subsystem initialization */ })

```

This file acts as the central registry, wiring together the audio, transcription, summarization, and notification subsystems so the frontend can call them by name.

### Audio Capture and Processing Pipeline

The `frontend/src-tauri/src/audio/` module handles the entire audio path. It discovers microphones and system devices, creates a **ring-buffer mixer** in [`frontend/src-tauri/src/audio/pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/pipeline.rs), runs **Voice Activity Detection (VAD)** to filter non-speech, and streams valid chunks to the transcription engine.

Platform-specific capture implementations live under `frontend/src-tauri/src/audio/devices/platform/`:

- **macOS** uses **ScreenCaptureKit** ([`macos.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/macos.rs))
- **Windows** uses **WASAPI**
- **Linux** uses **PulseAudio**

This abstraction keeps the rest of the stack OS-agnostic while the core pipeline handles mixing and level monitoring uniformly.

### Speech-to-Text Transcription Engines

Meetily supports two local transcription backends for **offline** speech recognition. The **Whisper** engine in [`frontend/src-tauri/src/whisper_engine/whisper_engine.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/whisper_engine/whisper_engine.rs) loads **Whisper-cpp** models and manages parallel processing. The **Parakeet** engine in [`frontend/src-tauri/src/audio/transcription/parakeet_provider.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/transcription/parakeet_provider.rs) provides an alternative higher-accuracy inference path.

When a new text chunk is ready, the backend emits a `transcript-update` event—commonly triggered by `whisper_engine::commands::whisper_transcribe_audio`—that the frontend consumes in real time.

### AI Summary Generation and LLM Routing

When the user requests a summary, the frontend invokes `api_process_transcript` defined in [`frontend/src-tauri/src/summary/commands.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/summary/commands.rs). This command routes the transcript to the selected provider.

Available backends include:

- **Builtin AI sidecar**: A local **llama-helper** process managed by [`frontend/src-tauri/src/summary/summary_engine/mod.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/summary/summary_engine/mod.rs) for fully on-device inference
- **External APIs**: Thin wrapper modules under `frontend/src-tauri/src/ollama/`, `openai/`, `anthropic/`, `groq/`, and `openrouter/` provide uniform access to cloud or self-hosted LLMs

A typical frontend call looks like this:

```typescript
await invoke('api_process_transcript', {
  meeting_id: meetingId,
  model: 'builtin', // or 'openai', 'ollama', etc.
});

```

The generated summary is streamed back to the UI and stored in the local **SQLite** database.

### Local SQLite Database and Persistence

All meetings, recordings, transcripts, and user preferences are stored in a **SQLite** database managed by `frontend/src-tauri/src/database/`. The [`frontend/src-tauri/src/database/setup.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/database/setup.rs) file creates the database on first launch, applies migrations, and places the file in the platform-specific app-data folder. As implemented in the Meetily source code, this guarantees that data remains local unless the user explicitly opts into an external LLM call.

### Notifications and User Analytics

The `frontend/src-tauri/src/notifications/` module wraps `tauri_plugin_notification` to display system-tray alerts and supports Do-Not-Disturb mode. Usage events are recorded only under user consent by the `frontend/src-tauri/src/analytics/` module. Both systems are toggled from the UI and invoked through dedicated Rust commands such as those in [`frontend/src-tauri/src/notifications/commands.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/notifications/commands.rs).

## Meetily External Services Architecture: LLM Providers

Although Meetily is designed to operate offline, it can optionally reach out to external LLM services for summarization. According to the Zackriya-Solutions/meetily source code, the architecture treats these providers as pluggable backends. Whether the user selects a local Ollama instance or a remote OpenAI API, the request flows through the same `summary::commands::api_process_transcript` entry point before being dispatched to the appropriate client wrapper.

## Cross-Platform Audio Abstraction in Meetily

Professional audio workflows require platform-specific backends, but Meetily avoids duplicating business logic by isolating OS differences under `frontend/src-tauri/src/audio/devices/platform/`. The [`macos.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/macos.rs) file implements ScreenCaptureKit capture, while equivalent modules target WASAPI on Windows and PulseAudio on Linux. The core `audio` API abstracts these details so that the VAD, mixing, and transcription layers remain unchanged across platforms.

## Summary

- Meetily uses a **three-layer architecture**: a Next.js/React frontend, a Rust core backend, and optional external LLM services.
- The **frontend** controls recordings and displays transcripts by invoking Tauri commands like `start_recording_with_devices_and_meeting` and listening for `transcript-update` events.
- The **Rust backend** in `frontend/src-tauri/src/` manages device discovery, ring-buffer mixing, VAD filtering, Whisper/Parakeet transcription, SQLite persistence, and system notifications.
- **Summary generation** is handled by `summary::commands::api_process_transcript`, which can target a local sidecar or external APIs including Ollama, OpenAI, Anthropic, Groq, and OpenRouter.
- **Cross-platform audio support** is achieved through pluggable device backends for macOS, Windows, and Linux without altering the core audio pipeline.

## Frequently Asked Questions

### What is the entry point for the Meetily Rust backend?

The entry point is [`frontend/src-tauri/src/lib.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/lib.rs). Its `run()` function constructs the Tauri app, registers all commands via `#[tauri::command]`, initializes the Whisper and Parakeet engines, and sets up the builtin-AI summary sidecar before the UI window appears.

### How does Meetily stream live transcripts to the UI?

The Rust backend emits a `transcript-update` event each time the Whisper or Parakeet engine produces a new text chunk. The frontend listens through Tauri’s `listen` API and updates React state immediately, creating a real-time feed without polling the backend.

### Where does Meetily store meeting recordings and transcripts?

All data is stored in a local SQLite database initialized by [`frontend/src-tauri/src/database/setup.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/database/setup.rs). The database lives in the platform-specific application data directory, ensuring that transcripts and summaries remain on the user's device unless an optional external LLM is used.

### Can Meetily transcribe and summarize meetings without an internet connection?

Yes. Meetily ships with local Whisper and Parakeet engines for speech-to-text and a builtin `llama-helper` sidecar for summarization. External LLM providers are entirely optional, so transcription, storage, and local summarization all function offline.