studio

Desktopowe narzędzie do moodboardów, cięć i sesji, oparte na wspólnym rdzeniu (Rust + Tauri). Tam, gdzie liczy się dostęp do plików, praca offline i szybkość natywnej aplikacji. Jedno repo, wspólny core, osobne aplikacje.

TL;DR

Desktopowe narzędzie deweloperskie do pracy z moodboardami, cięciami i sesjami, zbudowane na Rust + Tauri. Szybki dostęp do plików i praca offline, natywna szybkość zamiast karty w przeglądarce, a przy tym jedno repo i wspólny rdzeń zamiast osobnego kodu na każdą platformę.

Wprowadzenie

studio to narzędzie deweloperskie na pulpit, które obsługuje pracę z moodboardami, cięciami i sesjami - rzeczy, przy których liczy się ciągły, szybki dostęp do plików na dysku. Ten case study dotyczy tego, jak zbudować takie narzędzie natywnie, nie mnożąc przy tym kodu na każdy system operacyjny.

Założenie było dwustronne. Z jednej strony narzędzie ma czuć się jak natywny program: pliki pod ręką, działanie bez sieci, płynność nawet przy dużej sesji. Z drugiej - ma zostać jednym repozytorium i jednym rdzeniem, a nie trzema osobnymi aplikacjami, które potem trzeba potrójnie utrzymywać.

Czego przeglądarka nie da

Praca z moodboardami i cięciami to ciągłe sięganie do dysków: setki plików, katalogi projektów, podglądy, które mają pojawiać się natychmiast. Przeglądarka trzyma to wszystko za ścianą sandboxa. Każdy dostęp do pliku to dialog, brak sieci to brak aplikacji, a przy większej sesji interfejs zaczyna się krztusić.

Chcieliśmy narzędzia, które ma pliki pod ręką jak natywny program, działa bez sieci i nie zwalnia przy dużej sesji. Ale bez pułapki, w którą łatwo wpaść przy natywnym pisaniu: osobnego kodu na Windows, macOS i Linux, który potem rozjeżdża się między platformami i mnoży pracę przy każdej zmianie.

Dlaczego Tauri, a nie Electron

Tauri odwraca układ znany z Electrona. Interfejs piszesz raz, webowo, ale nie wozisz ze sobą całej przeglądarki - okno korzysta z systemowego silnika renderującego, a cała cięższa robota, dostęp do plików i logika siedzą w rdzeniu w Rust. Efekt to binarium liczone w megabajtach, nie setkach megabajtów, i realny dostęp do systemu, którego opakowana strona nigdy nie miała.

Różnica nie jest kosmetyczna. Electron dowozi własną kopię silnika przeglądarki do każdej aplikacji, więc każde narzędzie płaci za to samo Chromium od nowa. Tauri korzysta z tego, co system już ma, i dokłada tylko cienką warstwę własną. Przy narzędziu, które ma być szybkie i lekkie, to jest różnica między działa a działa natychmiast.

Tauri vs Electron

Cecha	Tauri	Electron
Silnik renderujący	systemowy	własna kopia Chromium
Rozmiar binarium	megabajty	setki megabajtów
Rdzeń logiki	Rust	Node.js
Dostęp do systemu	natywny, przez komendy	przez warstwę przeglądarki

Web rysuje, Rust robi

Podział jest czysty i to on trzyma całą architekturę w ryzach: web rysuje, Rust robi. Widoki moodboardów i cięć są pisane raz, webowo, a operacje na plikach, indeksowanie i wszystko, co ma być szybkie i offline, przechodzi przez komendy Tauri do rdzenia, który nic nie wie o wyglądzie.

Rdzeń w Rust jest samodzielną biblioteką: wczytywanie plików, indeksowanie, model sesji. Nie zależą od tego, kto go rysuje, więc tę samą logikę da się testować bez interfejsu i wystawiać tym samym kontraktem na każdej platformie. Widok to cienka warstwa na wierzchu, a nie miejsce, w którym mieszka wiedza o projekcie.

commands.rs · rust

#[tauri::command]
fn open_moodboard(path: String) -> Result<Moodboard, String> {
    Moodboard::load(&path).map_err(|err| err.to_string())
}

repo, wspólny rdzeń w Rust

platformy z jednego źródła

100%

funkcji dostępnych offline

Granica, której pilnujemy

Czysty podział ma jeszcze jedną zaletę: jest tylko jedno miejsce, w którym trzeba pilnować błędów na poważnie. Wewnątrz rdzenia ufamy własnym typom - jeśli sesja jest załadowana, jej model jest poprawny. Ale ścieżka do pliku przychodząca z widoku to wejście z zewnątrz. Może nie istnieć, może wskazywać na uszkodzony plik, może być resztką po przeniesionym projekcie.

Dlatego walidacja siedzi dokładnie na granicy - na komendzie Tauri - a nie jest rozsmarowana po całym rdzeniu na wszelki wypadek. Tam, gdzie web spotyka się z Rustem, błąd zamienia się w czytelny komunikat dla użytkownika; głębiej już nie musimy sprawdzać tego samego drugi raz.

Informacja

Granica między webem a rdzeniem to jedyne miejsce, gdzie pilnujemy błędów na poważnie. Wewnątrz rdzenia ufamy własnym typom, ale ścieżka do pliku z widoku to wejście z zewnątrz - i dopiero tu, na komendzie Tauri, zamienia się w czytelny komunikat, zamiast wywrócić aplikację głębiej.

Rdzeń w Rust

wczytywanie plików, indeksowanie i model sesji jako biblioteka niezależna od interfejsu.

Interfejs webowy

widoki moodboardów i cięć pisane raz, spięte z rdzeniem przez komendy Tauri.

Praca offline z założenia

dane i pliki trzymane lokalnie, sync jest opcją, nie warunkiem uruchomienia.

Jeden przebieg na trzy platformy

build z tego samego źródła na Windows, macOS i Linux, bez osobnych gałęzi kodu.

Jaki jest finalny efekt

Narzędzie startuje szybko, ma pliki pod ręką i nie potrzebuje sieci, żeby działać - a mimo to nie mnoży kodu na każdy system. Jedno repo, jeden rdzeń w Rust, cienka warstwa widoku na wierzchu i osobne aplikacje na wyjściu, zbudowane z tego samego źródła.

Dla osoby, która z tego korzysta, to znaczy tyle, że narzędzie zachowuje się jak natywny program, a nie jak strona udająca aplikację: pliki wskazujesz wprost z dysku, praca idzie dalej bez sieci, a interfejs nie krztusi się przy dużej sesji. Dla utrzymania - że nowa funkcja dodana w rdzeniu trafia na wszystkie trzy platformy naraz, zamiast być pisana i psuta trzy razy osobno.

Pliki pod ręką jak w natywnym programie, jeden rdzeń w Rust pod spodem, trzy platformy z jednego źródła.

Więcej projektów

Inne realizacje z tej samej kategorii - zobacz, jak podchodzimy do podobnych wyzwań.

Masz podobny projekt?

Napisz do nas - wycena jest bezpłatna i wraca w godzinę.