Mühendislik · mimari notlar · 12 dk okuma
Tauri v2 ve Rust ile Yerel AI Agent Geliştirmek: Mimari Notlar
Ilura'yı Electron yerine Tauri 2 + Rust ile yazdık. Performans, güvenlik, paket boyutu — gerçek sayılar ve mimari kararlar. Doğrulamalı yerel AI agent için niye Tauri.
Electron 180 MB; Tauri 25 MB. Aynı UI, dokuzda bir paket boyutu — kullanıcı bunu fark ediyor.
TL;DR
Ilura, kullanıcının kendi AI agent’ını yetiştirip ekipte paylaştığı bir masaüstü uygulaması. Electron yerine Tauri 2 + Rust + React seçtik. Bu yazıda kararın arkasındaki mimari düşünce, gerçek performans sayıları ve takıldığımız yerleri anlatıyorum.
Sonuç: 25 MB indirme, 80 MB boşta bellek, 1 saniye altı açılış, derin OS entegrasyonu, doğrulamalı politika motoru. Aynı UI’ı Electron’la yapsaydık 7-9 kat daha büyük bir uygulama olurdu — kullanıcının fark ettiği bir fark.
Niye yerel AI agent?
Cloud AI (ChatGPT, Claude, Gemini) hızlı başlıyor ama üç sınırı var:
- Veri gizliliği — kullanıcı verileri sağlayıcı sunucularına gider. KVKK §9 (yurt dışı aktarımı) Türk şirketler için sözleşmesel önlem ister; mimari değil.
- Bağımlılık — sağlayıcının fiyat artışı, model değişikliği, region kısıtlaması — kontrol kullanıcının elinden çıkar.
- Yetiştirilemezlik — system prompt + memory feature yüzeysel; agent’ın senin tarzına gerçekten yetişmesi mümkün değil.
Yerel-öncelikli mimari (Llama 3.1 8B / Mistral 7B / Qwen 2.5 7B) bu üç sınırı aşar. Ama yerel AI agent masaüstü uygulaması demek — burada Electron tercihi sorgulamaya değer.
Niye Electron değil
Electron 2013’ten bu yana cross-platform desktop’un fiili standardı. VSCode, Slack, Discord, Notion — hepsi Electron. Çekici sebepler var: tek codebase, geniş ekosistem, geliştirici familiarite. Ama üç gerçek:
1. Paket boyutu
VSCode 350 MB, Slack 250 MB, Notion 280 MB. Chromium runtime + Node + uygulama kodu üst üste. İlk indirme deneyimi kötü — özellikle Türk kullanıcıların ortalama internet hızı düşünüldüğünde.
Bizim için 350 MB’lık bir indirme demek “vazgeçirici”. 25 MB’lık bir indirme demek “denerim”.
2. Bellek kullanımı
Electron boşta 200-450 MB RAM. Yerel AI uygulaması yerel modeli (8 GB RAM tipik) çalıştırırken extra 400 MB istemiyoruz — kullanıcının laptop’ı zorlanmasın.
3. Native API erişimi
Electron WebView’a sınırlı. macOS Accessibility API, Windows UIA, Linux AT-SPI2 — bunlara erişim kötü. Bizim agent’ın UI otomasyonu yapması gereken senaryolar var (kullanıcının izniyle); Electron yetersiz.
Tauri 2 — Rust + WebView
Tauri ekibinin resmi tanımıyla:
“Tauri is a framework for building tiny, fast binaries for all major desktop platforms. Developers can integrate any frontend framework that compiles to HTML, JS and CSS for building their user interface. The backend of the application is a Rust-sourced binary with an API that the frontend can interact with.” — Tauri 2 Documentation
Farklı bir yaklaşım:
- Sistem WebView kullanır (macOS WebKit, Windows WebView2, Linux WebKitGTK) — ayrı Chromium yok
- Rust backend — Node yerine
- Type-safe IPC — WebView ↔ Rust arasında köprü
Sonuç:
| Eksen | Electron | Tauri 2 |
|---|---|---|
| Paket boyutu | 120-350 MB | 5-25 MB |
| Bellek (boşta) | 200-450 MB | 60-120 MB |
| Açılış | 2-3 sn | <1 sn |
| Native API | Sınırlı | Native (Rust crate’lerle) |
| Backend dili | Node.js | Rust |
Aynı UI (React + Mantine), 1/3 bellek, 1/9 paket boyutu.
Bizim mimari katmanımız
Yüksek seviyede üç katman:
┌─────────────────────────────────────┐
│ React UI (Mantine + Tabler) │ ← Kullanıcı yüzeyi
├─────────────────────────────────────┤
│ Type-safe IPC köprüsü │ ← Auto-gen TS bindings
├─────────────────────────────────────┤
│ Rust backend (tokio async) │ ← Karar motoru
│ ├─ Politika motoru │
│ ├─ Audit zinciri │
│ ├─ MCP transport │
│ └─ Yerel inference köprüsü │
├─────────────────────────────────────┤
│ Native OS (macOS / Windows / Linux)│
└─────────────────────────────────────┘
Her katman tek-yön: kullanıcı ↔ React, React ↔ Rust IPC, Rust ↔ OS. React’te iş mantığı yok; sadece görüntü. Tüm güvenlik kararları backend’de.
Bu disiplin kasıtlı: WebView’da çalışan kod compromise olsa (örn. zararlı bir markdown render’ı XSS yaratsa) bile kritik güvenlik kararları arka tarafta. Kullanıcı agent’ın yapacağı her eylemi politika motorundan geçtikten sonra görüyor.
HTTP istemci disiplini — bir desen
Yerel AI agent dış servislere HTTP istek atıyor (eğitmen API’leri, MCP sunucuları, bulut köprüsü). Naif yaklaşım: her çağrı yerinde yeni bir HTTP istemcisi oluştur. Sonuç: her istemci kendi connection pool’u kurar, bellek artar, retry/timeout politikaları tutarsız olur.
Bizim disiplinimiz: tek tip + paylaşılan istemci. Üç profil:
| Profil | Connect timeout | Total timeout | Kullanım |
|---|---|---|---|
| Default | 10 sn | 30 sn | Çoğu API çağrısı |
| Long-running | 10 sn | 5 dk | Eğitmen modele LoRA istekleri |
| Streaming | 10 sn | yok | Sohbet streaming |
Üç istemci bir kez global olarak kurulur, her çağrı bunlardan birini kullanır. Kod review’da ham HTTP istemci konstrüksiyonu engellenir — pre-commit hook ile yakalanır.
Bu disiplinin pratik kazancı:
- Connection pool tek noktadan yönetiliyor — bellek tasarrufu
- Timeout politikaları tutarlı — agent kararı 30 saniyede ya gelir ya net hata
- Retry / circuit breaker tek yerde uygulanır
Yüzlerce çağrı yeri tek istemciden geçer; her yer kendi politikasını uydurmaz.
Doğrulamalı yerleşim — politika motoru
AI agent’ların geniş yetkisi var: dosya okuyup yazıyor, mail atıyor, API çağırıyor, subprocess başlatıyor. Bu yetki yanlış elde olduğunda risk büyük (prompt injection, tool misuse, data exfiltration).
NIST’in zero-trust mimari için yayınladığı SP 800-207 dokümanından:
“Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location… Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established.” — NIST SP 800-207, Zero Trust Architecture
Geleneksel güvenlik modeli “agent içerden geliyor, güveniyoruz” yaklaşımına dayanıyor. Bu varsayım 2020’lerin gerçeğinde çürük — Snowden, SolarWinds, MOVEit hepsi içerden başlayan ihlaller.
Bizim yaklaşım: her eylem her seferinde doğrulanır. Agent’ın yapacağı her IPC çağrısı politika motorundan geçer ve dört sonuçtan biriyle döner:
Agent eylem önerisi
│
▼
[Politika motoru]
│
├─► İzin ver (düşük risk; otomatik)
├─► Reddet (politika ihlali; gerekçe loglanır)
├─► Onay iste (orta-yüksek risk; UI'da kullanıcı butonu)
└─► Biyometrik (kritik risk; Touch ID / FIDO2)
Politika kontrolleri:
- Path traversal koruması —
../../../etc/passwdbenzeri yollar reddedilir - Allow-list — hangi dosya tipleri, hangi dış API’ler izinli
- Pod izolasyonu — agent A pod’undan B pod’una geçemez (KVKK §6 kapsamına giren özel nitelikli veri için kritik)
- Saat sınırı — iş saati dışında yüksek-risk eylem reddedilir
- Quota — günlük dosya yazma sınırı, API çağrı sınırı
Politika kararı tipik bir milisaniye altında. UX’te fark edilmiyor; ama her eylem için kanıt üretiliyor.
Audit zinciri — kanıt üretimi
Politika kararı tek başına yetmez; “ne zaman ne karar verildi” sorusunun yanıtı saklanmalı. Bunu append-only hash zinciri ile yapıyoruz:
Kayıt N-1 ──hash──┐
▼
Kayıt N: { eylem, agent_id, kullanıcı_kararı,
önceki_kayıtın_hash'i, ECDSA imza }
│
└──hash──► Kayıt N+1
Her kayıt önceki kaydın hash’ini içerir. Bir kaydı sonradan değiştirmek imkansız — zincir kırılır, doğrulama başarısız olur.
ECDSA imzası kayıt sahibini doğrular. KVKK denetiminde “şu işlem yapıldı, kim onayladı, ne zaman” sorusuna kriptografik kanıt zinciri sunulur.
Yazma maliyeti: kayıt başına ~8 ms (Apple Silicon M2 üzerinde). Saniyede 100+ kayıt yazılabiliyor; agent için yeterli.
MCP transport — açık standart, doğrulamalı uygulama
Model Context Protocol (Anthropic, 2024) AI agent’ların dış araçlara erişim standardı. İki transport destekliyoruz: Stdio (yerel subprocess) ve SSE (HTTP üzerinden).
Stdio transport bir kullanım kolaylığı sağlar ama güvenlik riski getiriyor: subprocess olarak gelişigüzel binary çalıştırılırsa kod yürütme açığı doğar (sektörün 2026 başında bu kategoriyi vurgulayan public advisory’leri var).
Bizim yaklaşım: subprocess spawn’ı politika motorundan geçer. Spawn isteği geldiğinde:
- Binary path validate edilir (allow-list, hash kontrolü)
- Argümanlar sanitize edilir
- Kritik risk olarak işaretlenir → biyometrik onay zorunlu
- Onaylanırsa subprocess başlatılır, audit zincirine kayıt eklenir
Bu MCP’yi kullanılabilir tutarken, “open standard” demenin getirdiği saldırı yüzeyini kontrol altında tutuyor.
Performans — gerçek sayılar
Apple Silicon M2 Mac, 16 GB RAM:
| Metrik | Ölçüm |
|---|---|
| Tauri uygulaması açılışı | 0.7 sn |
| React UI ilk paint | 1.1 sn |
| İlk yerel inference (Llama 3.1 8B) | 4.5 sn (model yüklenmesi dahil) |
| İkinci inference | 1.2 sn (300 token output) |
| MCP server başlatma | ~200 ms |
| Audit kayıt yazma | ~8 ms |
| Politika kararı | <1 ms |
| Boşta bellek (model yüklü değil) | ~80 MB |
| Bellek (Llama 8B yüklü) | ~8.5 GB |
Karşılaştırma — aynı işi Electron + Node.js ile yapsak:
| Metrik | Electron tahmini |
|---|---|
| Açılış | 2.5-3 sn |
| Boşta bellek | ~350 MB |
| Politika kararı | 5-10 ms (V8 + IPC overhead) |
Politika motoru her IPC’de çalıştığı için alt milisaniye gecikme önemli — kullanıcı agent’ın “yavaş” olduğunu hissetmiyor.
Cross-compile macOS → Windows
Geliştirme makinesinde macOS’ten Windows binary üretebiliyoruz. MinGW toolchain Apple Silicon’da çalışıyor; CI’da Windows runner daha hızlı olduğu için production build’ler orada — ama acil iterasyon için yerel cross-compile pratik.
Bunun pratik faydası: bir Mac geliştiricinin Windows kullanıcılarının yaşadığı sorunu reproduce edip düzeltmesi mümkün. Ayrı bir Windows VM’e ihtiyaç yok.
Hangi durumda Tauri seçmemelisin?
Dürüst olalım — Tauri her zaman doğru cevap değil:
- Geniş Node ekosistemi gerekli — uygulamanın derinliğinde 50+ Node modülü varsa (özel video processing, native bindings vs.), Electron’a geçiş kolay olur. Tauri’de Node entegrasyonu ek iş.
- Geliştirici ekibi Rust bilmiyor — 6 aylık öğrenme eğrisi takım hızını etkiler. Hızlı prototip için Electron daha pragmatik.
- Plugin ekosistemi olgunlaşmamış — Tauri 2 plugin sayısı 100+ ama Electron 1000+. Niş ihtiyaçta Electron kütüphane bulma şansı yüksek.
- 3D / oyun / heavy graphics — Tauri WebView Chromium kadar performans vermiyor; native OpenGL/Metal entegrasyonu zorunluysa C++/Rust direkt window framework (winit) düşün.
Bu dört durum dışında Tauri 2 ciddi bir alternatif.
Sonuç
Tauri tercihi mimari karar — doğrulamalı AI agent için Rust’ın tip-system zorlaması + Tauri’nin küçük paket boyutu + native OS entegrasyonu üçü beraber daha sıkı bir ürün üretiyor. Electron’un VSCode/Slack için çalıştığı yer farklı; bizim için yerel-öncelikli AI agent + KVKK çerçevesi + denetlenebilir audit zinciri üçlüsünde Tauri net kazanıyor.
Eğer yerel AI uygulaması yazıyorsan ve Electron alışkanlığını sorgulayabiliyorsan — Tauri 2 ile bir prototip yap. Bir hafta yeterli; performans farkı 10 dakikada belli oluyor.
Kaynaklar
- Tauri 2 Documentation — v2.tauri.app
- Tauri GitHub — github.com/tauri-apps/tauri
- NIST SP 800-207 — Zero Trust Architecture — nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
- Model Context Protocol Specification — Anthropic, 2024 — modelcontextprotocol.io/specification
- Anthropic Building Effective Agents — anthropic.com/research/building-effective-agents
- Rust Async Book — rust-lang.github.io/async-book
- Tokio Runtime — tokio.rs
- Microsoft Trusted Signing — learn.microsoft.com/en-us/azure/trusted-signing
- Apple Notarization — developer.apple.com/documentation/security/notarizing-macos-software
- Ilura Tezgah indir — ilura.com.tr/indir (.dmg, .msi, .AppImage)
Hacker News tartışmasına ve sorularınıza buradan açığım. Soru, eleştiri, alternatif perspektif — hepsi makbule geçer.