Dov'è esattamente la riga fra un sito e un'applicazione su misura, perché uno si conta a pagine e l'altra a stati, e che cosa succede alle pagine già fatte il giorno in cui qualcuno chiede di vedere «solo le sue».
di Nadia Maar ·
La domanda arriva quasi sempre nella forma sbagliata: «meglio un sito o una web app?». Detta così non ha una risposta, perché nessuno dei due è una scelta di gusto o di ambizione — sono due mestieri diversi, con due modi diversi di fare i prezzi, e si finisce nel secondo per accumulo. Un progetto parte come sito, riceve quattro richieste ragionevoli una alla volta, e a un certo punto è un'altra cosa: senza che nessuno l'abbia deciso, senza che nessuno l'abbia detto, e con il preventivo ancora fermo a quello di prima.
Il punto di questo pezzo è che la riga esiste, è netta, e non passa dove tutti la cercano. Non è il numero di pagine, non è quanto è bello il disegno, non è se c'è un'animazione. La riga è una sola, ed è questa: a un certo punto qualcosa nel sistema comincia ad appartenere a qualcuno. Finché ogni visitatore può vedere la stessa identica risposta, siete su un sito e costa quello che costa un sito. Nell'istante in cui un dato è «di quel cliente e non degli altri», servono identità, autorizzazione e un registro — e sono tre sistemi, non tre pagine.
La parte che sorprende, e che nei preventivi non compare mai, è che il varco non costa solo quello che c'è oltre: rimette in gioco anche ciò che era già stato fatto e pagato. Qui sotto c'è la sequenza esatta con cui succede, che cosa cambia nel modo di contare, e come si decide prima invece di scoprirlo a metà progetto.
Questa è una sequenza vera, nell'ordine in cui arriva. Ogni richiesta, presa da sola, sembra piccola: è il motivo per cui vengono tutte accettate. La riga rossa è il punto in cui il progetto cambia mestiere — e da lì in poi, guardate il marchio che compare sulle richieste già accettate sopra.
Contenuto uguale per tutti, che si calcola una volta e si serve a chiunque. È il caso in cui un sito costa poco davvero: la stessa risposta vale per il primo visitatore e per il centomillesimo, si può tenere in copia ovunque nel mondo, e non c'è niente da proteggere perché non c'è niente di privato.
Nessun effetto su altro: è una pagina, e resta una pagina.
Il modulo raccoglie e spedisce. Non ricorda: quello che è stato inviato vive nella vostra casella di posta, non nel sistema. È ancora un sito, perché non c'è niente da conservare, da mostrare di nuovo, o da mostrare a una persona e non a un'altra.
Aggiunge una dipendenza — chi spedisce la posta — e nient'altro.
Un file dietro un collegamento. Finché è lo stesso file per tutti è contenuto, esattamente come un'immagine: si carica, si sostituisce, si serve. Molti pensano che sia già un'area riservata. Non lo è, e questa distinzione vale l'intero articolo.
Nessuno. È la richiesta che sembra più vicina al varco e invece non lo tocca nemmeno.
Qui cambia il mestiere, e cambia in una riga. Perché esista «il suo» listino bisogna sapere chi è: identità. Perché non veda quello di un altro serve una regola che lo impedisca: autorizzazione. E perché quella regola valga anche quando qualcuno indovina un indirizzo o chiama l'API a mano, deve stare nel database, non nella pagina. Non è una pagina in più: sono tre sistemi che prima non c'erano.
E le tre richieste qui sopra vanno rifatte: la pagina dei servizi ora esiste in due versioni, dentro e fuori; il modulo deve sapere chi scrive; e il PDF non può più stare a un indirizzo pubblico che un cliente può inoltrare a un concorrente.
Scrittura, non più lettura. Serve un secondo tipo di utente con poteri diversi dal primo, un posto dove le modifiche vengono controllate prima di valere, e un comportamento deciso in anticipo per quando due persone toccano la stessa riga nello stesso minuto. Quest'ultima non è un caso raro: è il normale martedì mattina di un ufficio commerciale.
Raddoppia i percorsi da provare: ogni schermata esiste adesso nella versione di chi guarda e in quella di chi modifica.
Un registro. Non è una funzione da aggiungere in fondo: è un vincolo su come vengono scritte TUTTE le modifiche, perché un registro compilato a metà è peggio di nessun registro — dà una certezza che non ha, e la prima volta che serve davvero è anche la prima volta che si scopre che manca una riga.
Tocca ogni scrittura già esistente, comprese quelle fatte nelle settimane in cui il registro non era ancora stato chiesto.
La colpa non è della quarta richiesta, ed è l'errore che si fa quando si scopre il conto: quella richiesta è quasi sempre legittima e spesso è la ragione commerciale dell'intero progetto. Il problema è averla ricevuta dopo aver preventivato le prime tre come se non dovesse arrivare mai.
Non «sito o applicazione?», ma: «c'è qualcosa che una persona deve vedere e un'altra no?». Se la risposta è sì, anche per una cosa sola, anche fra un anno, siete oltre il varco e tanto vale saperlo adesso — quando costa una decisione invece di una riscrittura.
È qui che i preventivi divergono, e il motivo è aritmetico, non commerciale. Il lavoro di un sito cresce insieme alle pagine: dieci pagine costano circa il doppio di cinque. Il lavoro di un'applicazione cresce insieme agli stati, cioè alle combinazioni di chi sei, che cosa stai guardando e in che condizione si trova — e le combinazioni si moltiplicano fra loro invece di sommarsi.
| Sito | Applicazione su misura | |
|---|---|---|
| Che cosa fa crescere il lavoro | Il numero di pagine | Il numero di stati: ruoli × schermate × condizioni |
| Come cresce | Sommando: una pagina in più è una pagina in più | Moltiplicando: un ruolo in più raddoppia tutto ciò che esiste già |
| Che cosa si prova prima di pubblicare | Che ogni pagina si apra e si legga bene | Che ogni ruolo veda ciò che deve e NON veda il resto — la seconda metà è la più lunga |
| Che cosa succede se sbagliate | Una pagina brutta, o un testo vecchio | Un cliente che vede i prezzi di un altro cliente |
| Dove vive la regola | Nel disegno della pagina | Nel database, perché deve valere anche per chi la pagina non la apre |
| Il costo dopo la consegna | Aggiornare contenuti | Tenere in piedi identità, permessi, copie di sicurezza e registro |
Le prime cinque righe spiegano la differenza di lavoro; l'ultima spiega la differenza di responsabilità. Un sito che si rompe fa una brutta figura. Un'applicazione che si rompe nel posto sbagliato mostra a un cliente i dati di un altro — ed è per questo che un preventivo serio per un'applicazione contiene voci che su un sito non esistono affatto, e che a prima lettura sembrano gonfiate.
Superata la riga, entrano nel progetto tre pezzi che prima non avevano ragione di esistere. Non sono opzioni e non si rimandano alla seconda fase: sono il motivo per cui il preventivo cambia, e vale la pena riconoscerli per nome quando li leggete.
Chiedete a chi vi sta preventivando: «se un cliente indovina l'indirizzo del documento di un altro cliente, che succede?». Se la risposta parla di come è fatta la pagina, il progetto sta trattando un'applicazione come un sito. Se parla di una regola sul dato, siete nel posto giusto.
La differenza si vede in due tabelle. Si somigliano moltissimo — hanno entrambe delle colonne, un identificatore e una data — e in mezzo passa tutta la distanza fra le due professioni. Guardate solo una cosa: se la riga ha o non ha un proprietario.
-- PRIMA DEL VARCO. Un messaggio dal modulo di contatto.
-- Non ha un proprietario, perché non deve tornare indietro a nessuno:
-- entra, vi arriva per posta, e la sua vita finisce lì.
create table messaggi (
id bigint generated always as identity primary key,
inviato_il timestamptz not null default now(),
email text not null,
testo text not null
);
-- DOPO IL VARCO. Un prezzo. Ha un proprietario, e la regola che dice
-- chi lo vede NON sta nella pagina: sta qui sotto, dove vale anche
-- per chi la pagina non la apre nemmeno.
create table listino (
id bigint generated always as identity primary key,
cliente_id uuid not null references clienti (id),
articolo text not null,
prezzo numeric(10,2) not null,
-- il registro non e' una tabella che si aggiunge dopo: comincia qui
aggiornato_il timestamptz not null default now(),
aggiornato_da uuid not null references auth.users (id)
);
alter table listino enable row level security;
create policy "ognuno vede solo il proprio listino"
on listino for select
using (
cliente_id = (select cliente_id from profili where id = auth.uid())
);Le due tabelle differiscono per una colonna — cliente_id — e per le quattro righe in fondo. Quella colonna è il varco: dice che la riga appartiene a qualcuno. Le quattro righe sono la conseguenza: la regola che la protegge sta nel database, quindi vale per la pagina, per l'API, per lo script di un collega e per chiunque arrivi da una strada che non avevate previsto.
La scorciatoia più comune è controllare i permessi nell'interfaccia: se non sei tu, il pulsante non compare. Funziona finché qualcuno usa solo l'interfaccia. Una regola scritta sul dato invece non si può aggirare, perché non c'è nessuna strada che non ci passi attraverso — e sull'argomento c'è un pezzo intero in questo blog, dedicato a come si scrive.
La decisione si prende in una riunione, non in un documento di quaranta pagine, e si prende rispondendo a tre domande in quest'ordine. Se tutte e tre danno no, prendete un sito e state tranquilli per anni. Se anche una sola dà sì — anche in forma di «non adesso, ma probabilmente l'anno prossimo» — la scelta è già fatta, e conviene metterla nel preventivo di oggi.
Il moltiplicatore fra due e quattro è un intervallo osservato su progetti diversi, non un listino: dipende quasi interamente da quanti ruoli ci sono e da quante schermate cambiano faccia a seconda di chi guarda. Con un solo ruolo in più e tre schermate resta vicino al due; con quattro ruoli e un flusso di approvazioni si supera il quattro. Chi vi dà una percentuale precisa prima di aver contato i ruoli sta indovinando.
Se avete un preventivo per un sito in mano e nella lista delle funzioni c'è anche una sola riga che comincia con «il cliente potrà vedere», mandatecelo: in mezz'ora vi diciamo da che parte del varco siete davvero, quali voci mancano, e se conviene fare il sito adesso e l'applicazione dopo — che a volte è la risposta giusta.
E se dalle tre domande esce no tre volte, ve lo diciamo con la stessa chiarezza: vi serve un sito, non un'applicazione, e chi vi propone un portale con le credenziali per un catalogo che è uguale per tutti vi sta vendendo complessità che dovrete mantenere per anni senza averne mai avuto bisogno.
Sviluppo applicazioni web su misura
La riga è una sola: in un sito ogni visitatore può vedere la stessa identica risposta, in un'applicazione qualcosa appartiene a qualcuno. Non è il numero di pagine e non è la qualità del disegno. Nell'istante in cui un dato è «di quel cliente e non degli altri» servono identità, autorizzazione e un registro di chi ha cambiato cosa — e sono tre sistemi da mantenere, non tre pagine da disegnare.
L'intervallo tipico è fra il doppio e il quadruplo, ma il moltiplicatore non dipende dalla grafica: dipende da quanti ruoli esistono e da quante schermate cambiano faccia a seconda di chi guarda. Con un ruolo in più e tre schermate si resta vicini al due; con quattro ruoli e un flusso di approvazioni si supera il quattro. Chi vi dà una cifra precisa prima di aver contato i ruoli sta indovinando.
Tre domande, in quest'ordine. Qualcuno deve vedere qualcosa che un altro non deve vedere? Qualcuno deve poter cambiare dei dati dal browser, e le modifiche devono restare? Dovrete dimostrare fra sei mesi chi ha cambiato cosa? Se escono tre no, vi serve un sito e state tranquilli per anni. Se anche una sola dà sì — pure nella forma «non adesso, ma probabilmente l'anno prossimo» — conviene metterlo nel preventivo di oggi.
Dipende da dove vive la regola. Nascondere un pulsante a chi non è autorizzato protegge solo chi passa dall'interfaccia: chiunque chiami l'API direttamente, o indovini l'indirizzo di un documento, entra lo stesso. La regola che protegge davvero sta sul dato, nel database, dove vale per la pagina, per l'API, per lo script di un collega e per qualunque strada non avevate previsto. È la differenza fra «improbabile» e «impossibile», e costa molto meno se si decide all'inizio.