Appearance
Desktop App: Desktop-Specific Features & Data Flows
Part 4 of 5 in the Architecture & Foundation series.
This page covers what's unique to the desktop app — local SQLite storage, offline mode — and walks two end-to-end data flows: a code submission on the website, and offline browsing on desktop.
SQLite & FTS5: Local Database for Desktop
Why SQLite?
The web version relies on Firestore — cloud-based, real-time, always requiring internet. The desktop app can't make that assumption, so it uses SQLite: a local, file-based database engine with no server process. The app opens a .db file, queries it locally, and gets instant results.
What's Stored Locally
- All DSA problems (3,000+, with solutions, test cases, company tags)
- The user's notes, downloaded from Firestore and cached locally
- The user's progress: problems solved, OA scores, bookmarks
- Preferences: dark mode, font size, split-pane position
FTS5: Full-Text Search
FTS5 is a SQLite extension for fast text search. Without it, SELECT * FROM problems WHERE title LIKE '%binary search%' scans every row — around 500ms across 3,000+ problems. With it, SELECT * FROM problems_fts WHERE problems_fts MATCH 'binary search' uses a pre-built index instead, at roughly 5ms for the same data.
sql
-- Create FTS5 index
CREATE VIRTUAL TABLE problems_fts USING fts5(
id, title, content, tags, difficulty
);
-- Insert all problems into FTS5
INSERT INTO problems_fts
SELECT id, title, content, tags, difficulty FROM problems;
-- Search (instant)
SELECT * FROM problems_fts
WHERE problems_fts MATCH 'binary search'
LIMIT 20;A student types "binary search" → React sends it to the Tauri backend → Rust queries SQLite's FTS5 index → results return in about 5ms → the student sees results instantly, even offline.
Web vs. Desktop Database
| Aspect | Web (Firestore) | Desktop (SQLite) |
|---|---|---|
| Storage | Cloud (Google) | Local (user's device) |
| Internet required | Yes, always | No, after initial sync |
| Query speed | 100–500ms (network round trip) | 5–10ms (local disk) |
| Real-time sync | Instant across devices | Manual sync required |
| Search speed | Firestore search | FTS5 (instant) |
| Data privacy | Backed up by Google | Stays on device |
| Sync with Firestore | N/A — is Firestore | Optional, for backup |
Offline Mode: The Desktop Advantage
Initial setup (requires internet): on first launch, Tauri connects to Firestore and downloads all problems and user data into local SQLite — roughly 2 GB, taking 5–10 minutes on WiFi.
Offline mode (any time after): no internet required. All problems, notes, and preferences are available locally, and the student can browse, write code, and take notes freely. When submitting code, if Judge0 is reachable it runs immediately; if not, the submission is cached locally.
Back online: Tauri detects the connection, syncs cached submissions to Judge0 for grading, and syncs progress to Firestore as a backup.
Offline Flow Example
rendering diagram…
drag to pan · ctrl / ⌘ + scroll to zoom
A student can prep on a flight with no internet, and results sync automatically once online.
Website vs. Desktop: Key Differences
| Aspect | Website (ediky.com) | Desktop (Tauri App) |
|---|---|---|
| Access | Open browser, visit URL | Download, install, launch |
| Frontend tech | React 19 + Vite | React 19 + Vite (same) |
| Backend | Cloudflare Pages Functions + Workers | Tauri + Rust + SQLite |
| Database | Firestore (cloud) | SQLite (local) |
| Offline capability | Limited (cached pages) | Full (all data local) |
| Code execution | Always uses Judge0 (cloud) | Tries Judge0; caches if offline |
| Performance | Depends on network | Always fast (local) |
| Exam integrity | None (trusted network) | Full (system monitoring, vision, audit logs) |
| Setup | Zero (open browser) | One-click install |
| Real-time sync | Yes (Firestore listeners) | Manual sync when online |
| Searchability | Firestore search (100–500ms) | SQLite FTS5 (5ms) |
| Authentication | Firebase Auth | System-browser OAuth 2.0 + PKCE |
Both are the same UI, running on backends optimized for different constraints: web for always-online global scale and real-time sync, desktop for offline-first operation, OS integration, and exam integrity.
Data Flow: Code Submission (Website)
A student on ediky.com solves "Two Sum" in C++ and clicks Submit.
rendering diagram…
drag to pan · ctrl / ⌘ + scroll to zoom
React sends the request to a nearby Cloudflare edge, which forwards it to Judge0, logs the result to Firestore, and Firestore's real-time sync notifies other devices — around 200–500ms total, dominated by Judge0's compile-and-run time.
Data Flow: Offline Browsing (Desktop)
A student launches Ediky Desktop offline, browses problems, writes code, and takes notes.
rendering diagram…
drag to pan · ctrl / ⌘ + scroll to zoom
No network is needed for any of this — all data loads from local SQLite, code is cached while offline, and cached code runs automatically once the connection returns.
← Previous: Backend & Services→ Next: Security, Deployment & FAQ↩ Overview: Architecture & Foundation