studio
Uno strumento desktop per moodboard, tagli e sessioni, su un core condiviso (Rust + Tauri). Dove contano l'accesso ai file, il lavoro offline e la velocità di un'app nativa. Un repo, un core condiviso, app separate.
Uno strumento di sviluppo desktop per lavorare con moodboard, tagli e sessioni, costruito su Rust + Tauri. Accesso rapido ai file e lavoro offline, velocità nativa invece di una scheda del browser, e per di più un unico repo e un cuore condiviso invece di codice separato per piattaforma.
Introduzione
studio è uno strumento di sviluppo desktop che gestisce il lavoro con moodboard, tagli e sessioni - il tipo di lavoro in cui conta un accesso costante e rapido ai file sul disco. Questo caso di studio riguarda come costruire uno strumento del genere in modo nativo senza moltiplicare il codice per ogni sistema operativo.
La premessa era a due facce. Da un lato lo strumento deve sembrare un programma nativo: file a portata di mano, funzionamento senza rete, fluido anche su una sessione grande. Dall'altro, deve restare un unico repository e un unico cuore, non tre app separate che poi vanno mantenute tre volte.
Cosa non può dare un browser
Lavorare con moodboard e tagli significa allungare la mano ai dischi di continuo: centinaia di file, directory di progetto, anteprime che devono comparire all'istante. Un browser tiene tutto questo dietro un muro di sandbox. Ogni accesso a un file è un dialogo, niente rete significa niente app, e su una sessione più grande l'interfaccia inizia a soffocare.
Volevamo uno strumento che avesse i file a portata di mano come un programma nativo, funzionasse senza rete e non rallentasse su una sessione grande. Ma senza la trappola in cui è facile cadere scrivendo in modo nativo: codice separato per Windows, macOS e Linux che poi si discosta tra le piattaforme e moltiplica il lavoro a ogni modifica.
Perché Tauri, non Electron
Tauri ribalta la disposizione nota da Electron. Scrivi l'interfaccia una volta, sul web, ma non ti porti dietro tutto un browser - la finestra usa il motore di rendering del sistema, mentre tutto il lavoro più pesante, l'accesso ai file e la logica stanno in un cuore Rust. Il risultato è un binario misurato in megabyte, non in centinaia di megabyte, e un accesso reale al sistema che una pagina impacchettata non ha mai avuto.
La differenza non è cosmetica. Electron consegna la propria copia del motore del browser con ogni app, cosicché ogni strumento paga di nuovo per lo stesso Chromium. Tauri usa ciò che il sistema ha già e aggiunge solo un sottile strato proprio. Per uno strumento che deve essere veloce e leggero, questa è la differenza tra funziona e funziona all'istante.
Tauri vs Electron
| Caratteristica | Tauri | Electron |
|---|---|---|
| Motore di rendering | quello del sistema | copia propria di Chromium |
| Dimensione del binario | megabyte | centinaia di megabyte |
| Cuore della logica | Rust | Node.js |
| Accesso al sistema | nativo, tramite comandi | tramite lo strato del browser |
Il web disegna, Rust fa
La divisione è pulita, ed è essa a tenere a freno tutta l'architettura: il web disegna, Rust fa. Le viste dei moodboard e dei tagli sono scritte una volta, sul web, mentre le operazioni sui file, l'indicizzazione e tutto ciò che deve essere veloce e offline passa attraverso comandi Tauri verso un cuore che non sa nulla dell'aspetto.
Il cuore Rust è una libreria autonoma: caricamento dei file, indicizzazione, il modello di sessione. Non dipendono da chi li disegna, cosicché la stessa logica si può testare senza interfaccia ed esporre con lo stesso contratto su ogni piattaforma. La vista è un sottile strato in cima, e non il posto in cui abita la conoscenza del progetto.
Il confine che presidiamo
La divisione pulita ha ancora un vantaggio: c'è un solo posto in cui gli errori vanno presidiati sul serio. All'interno del cuore ci fidiamo dei nostri tipi - se una sessione è caricata, il suo modello è valido. Ma un percorso di file che arriva dalla vista è un input dall'esterno. Può non esistere, può puntare a un file corrotto, può essere un residuo di un progetto spostato.
Perciò la validazione sta esattamente al confine - sul comando Tauri - e non è spalmata su tutto il cuore per ogni evenienza. Dove il web incontra Rust, un errore si trasforma in un messaggio leggibile per l'utente; più in profondità non dobbiamo più controllare la stessa cosa una seconda volta.
Il confine tra web e cuore è l'unico posto in cui presidiamo gli errori sul serio. All'interno del cuore ci fidiamo dei nostri tipi, ma un percorso di file dalla vista è un input dall'esterno - e solo qui, sul comando Tauri, si trasforma in un messaggio leggibile, invece di rovesciare l'app più in profondità.
caricamento dei file, indicizzazione e il modello di sessione come libreria indipendente dall'interfaccia.
viste dei moodboard e dei tagli scritte una volta, collegate al cuore tramite comandi Tauri.
dati e file tenuti localmente, la sync è un'opzione, non una condizione di avvio.
un build dalla stessa sorgente per Windows, macOS e Linux, senza rami di codice separati.
Qual è il risultato finale
Lo strumento si avvia in fretta, ha i file a portata di mano e non ha bisogno di rete per funzionare - e nonostante ciò non moltiplica il codice per sistema. Un repo, un cuore Rust, un sottile strato di vista in cima e app separate in uscita, costruite dalla stessa sorgente.
Per la persona che lo usa, ciò significa che lo strumento si comporta come un programma nativo, e non come una pagina che finge di essere un'app: punti ai file direttamente dal disco, il lavoro continua senza rete e l'interfaccia non soffoca su una sessione grande. Per la manutenzione, significa che una nuova funzione aggiunta nel cuore raggiunge tutte e tre le piattaforme contemporaneamente, invece di essere scritta e rotta tre volte separatamente.
File a portata di mano come in un programma nativo, un cuore Rust sotto, tre piattaforme da un'unica sorgente.
Altri progetti
Altri lavori della stessa categoria - scopri come affrontiamo sfide simili.
Hai un progetto simile?
Contattaci - il preventivo è gratuito e arriva entro un'ora.