Perché i tuoi strumenti dev dovrebbero girare lato client (e cosa watchare)

Ogni sviluppatore ha incollato un segreto in un formattatore online almeno una volta. Un file di configurazione con chiavi API. Un JWT che voleva ispezionare. Una regex che doveva testare su dati di produzione. Lo strumento online lo ha formattato, ha restituito un risultato e tutti hanno proseguito. Il problema: quel segreto ora è nel database di qualcun altro.

Gli runtime dei browser moderni possono fare quasi tutto ciò che un server può fare per gli strumenti dev. JavaScript è veloce. La Web Crypto API è solida. WASM significa che anche il parsing pesante (YAML, JSON Schema, regex) funziona localmente. Il risultato: una nuova generazione di strumenti dev che elaborano tutto lato client, non caricano mai i tuoi dati e non hanno nemmeno bisogno di un backend per funzionare.

Questo post parla di perché è importante, i casi in cui non funziona, e come distinguere le differenze.

Cosa significa realmente “lato client”

Uno strumento lato client è quello in cui il lavoro avviene nel tuo browser, non su un server. HTML, CSS e JavaScript vengono scaricati una volta. Da quel momento, ogni operazione è locale. Il server non è più nel ciclo.

Per un formattatore JSON, questo significa:

• Incollare JSON in un <textarea>.
• Il browser lo analizza, lo formattizza e visualizza il risultato.
• Nessuna chiamata fetch. Nessun endpoint API. Nessun servizio di logging.

Per un decodificatore JWT, significa:

• I tre segmenti base64 vengono decodificati nel browser.
• La firma viene verificata (o no) usando codice che funziona localmente.
• Il segreto non lascia mai la tua macchina.

Puoi verificarlo da solo in qualsiasi browser. Apri DevTools → Network, esegui l’operazione e osserva il log delle richieste. Uno strumento genuinamente lato client mostrerà zero richieste con i tuoi input.

Perché è meglio per gli strumenti dev

Privacy. Il vantaggio più ovvio. Il fornitore dello strumento non può divulgare ciò che non ha mai ricevuto. Non può essere citato in giudizio per log che non esistono. Non può vendere i tuoi dati perché non li possiede.

Latenza. Nessun andata e ritorno di rete. Un file JSON da 100KB richiede pochi millisecondi per essere formattato. Lo stesso file caricato su un server, formattato e scaricato potrebbe richiedere 200ms in un buon giorno. Per strumenti che usi decine di volte al giorno, questo si accumula.

Costo. Il fornitore dello strumento non paga per calcolo o archiviazione. Uno strumento lato client ha efficacemente un costo marginale zero per utente. Ecco perché molti di essi sono gratuiti.

Offline. Una volta caricata la pagina, lo strumento funziona senza connessione internet. Utile negli aerei, nei caffè con wifi instabile e in ambienti air-gapped.

Resilienza. Lo strumento non va in tilt quando il fornitore rimane soldi o decide di pivotare verso le criptovalute. Finché l’URL è raggiungibile, funziona.

I compromessi

Lato client non è gratuito. Ci sono ragioni reali per cui alcuni strumenti non possono prendere questa strada.

Limiti sulla dimensione dei file. La scheda del browser è un singolo processo. File molto grandi (centinaia di megabyte) possono bloccare la scheda. Uno strumento lato server può gestire flussi e dimensioni arbitrary. Per un formattatore JSON, tutto ciò che supera i ~50MB inizia a sembrare lento nel browser. Il formattatore JSON di DevSpeedTools gestisce questo bene; per file genuinamente enormi, uno strumento CLI con streaming è la risposta giusta.

Nessuna collaborazione. Se il tuo strumento deve condividere stato tra utenti — pensa a Figma, Google Docs, qualsiasi cosa multiplayer — hai bisogno di un server. Ma questo non è ciò che fanno la maggior parte degli strumenti dev. Un formattatore, un validatore, un decodificatore, un generatore — tutti sono operazioni per un singolo utente.

Nessuna analisi sui dati utente. I fornitori non possono vedere cosa fanno le persone con lo strumento. Questo è lo scopo. Ma significa anche che l’autore del tool non può debuggare facilmente i problemi segnalati dagli utenti. Buoni strumenti lato client forniscono messaggi di errore chiari e un modo per condividere esempi riproducibili senza condividere i dati effettivi.

Restrizioni sugli asset cross-origin. Se lo strumento deve recuperare dati da un’API di terze parti (ad esempio, un verifica JWT che deve recuperare un JWKS da un provider di identità), la configurazione CORS deve essere corretta. Per strumenti puramente locali, questa non è una preoccupazione.

Il download iniziale. I moduli WASM possono essere di qualche megabyte. Un grande parser YAML basato su WASM o un motore regex può richiedere un momento al primo caricamento. Visite successive sono memorizzate nella cache. La compilazione streaming (ora standard in Chrome e Firefox dal 2024) significa che il primo parsing avviene prima che l’intero modulo venga scaricato, quindi la preoccupazione si è ridotta da reale a minore. WebGPU, dove disponibile, permette agli strumenti dev computazionalmente intensivi (elaborazione immagini, criptografia, motori regex) di girare sulla GPU — ordini di grandezza più veloce di JavaScript per il carico di lavoro giusto.

Come verificare che uno strumento sia realmente lato client

La copia promozionale della maggior parte degli strumenti dev dice “lato client” o “nel browser” o “nessun caricamento”. La maggior parte di essi lo intende. Alcuni no. Ecco come verificare.

1. Apri DevTools → Network. Usa lo strumento. Osserva le richieste. Se lo strumento sta effettuando una POST a un’API con i tuoi dati, non è lato client. Se le uniche richieste sono per HTML, CSS e il bundle JS, sei a posto.
2. Visualizza sorgente. Tasto destro → Visualizza sorgente pagina. Trova il JavaScript. Se il lavoro pesante è in un tag script e funziona localmente, lo strumento è lato client. Se è tutto in un wrapper sottile attorno a un’API server, lo strumento non lo è.
3. Blocca la rete. DevTools → Network → “Offline”. Ricarica lo strumento (avrai bisogno della pagina in cache). Usa lo strumento. Se funziona ancora, lo strumento è genuinamente lato client.
4. Leggi la privacy policy. Cerca la riga “non raccogliamo” o “non registriamo” o “tutta l’elaborazione avviene nel tuo browser”. Un vago “valutiamo la tua privacy” è un segnale giallo.

Come sono i buoni strumenti dev lato client

I migliori strumenti lato client condividono alcune caratteristiche:

• Ti dicono che sono lato client. Spesso con un piccolo badge vicino all’input (“Elaborato localmente” o un’icona a forma di lucchetto).
• Funzionano offline. Una volta caricati, la pagina continua a funzionare senza rete.
• Gestiscono l’incollaggio di dati grandi con grazia. Un incollaggio da 10MB non dovrebbe bloccare il browser.
• Forniscono un modo per condividere uno stato tramite fragment URL. Ad esempio, uno strumento che codifica il tuo input in un fragment URL #data=... ti permette di condividere un esempio senza inviare i dati a un server. L’helper di condivisione DevSpeedTools fa esattamente questo.
• Hanno una nota sulla privacy. Una frase breve che spiega cosa fa lo strumento con il tuo input — solitamente “niente”.

Quando lato server è ancora la risposta giusta

Non tutto può o deve essere lato client:

• Strumenti che hanno bisogno di un database. Uno strumento “qual è il mio indirizzo IP” deve effettivamente vedere il tuo IP.
• Strumenti che devono chiamare API a pagamento. Uno strumento “riassumi questo articolo” chiama OpenAI. La chiave OpenAI non può girare nel browser.
• Strumenti che necessitano di accesso in scrittura a sistemi esterni. Qualsiasi cosa che pubblica su Slack o crea una PR su GitHub.
• Strumenti che devono aggregare tra utenti. Uno strumento “questo dominio è in una blocklist?” ha bisogno della blocklist condivisa.

La linea di demarcazione: se l’operazione è una funzione solo dell’input dell’utente, dovrebbe essere lato client. Se l’operazione necessita di stato condiviso, un server è inevitabile.

Il cambiamento nello spazio degli strumenti dev negli ultimi cinque anni è stato drammatico. Strumenti che richiedevano un backend (formattatori, validatori, decodificatori, generatori) ora funzionano interamente nel browser. Il pattern è semplice: scarica una volta, esegui per sempre, non inviare nulla. Per gli sviluppatori che lavorano con configurazioni sensibili o token di produzione, questo spostamento è un miglioramento significativo in termini di sicurezza.