Il 19 giugno 2025 sono stato a PiterJS #79 a San Pietroburgo. La serata aveva un tema piacevolmente poco appariscente: non come spedire la prossima feature, ma come mantenere ciò che è già stato costruito — monitoring, deployment e refactoring.
Il programma seguiva bene questo filo. Pavel Shlykov ha parlato di come migliorare un vecchio monolite, Alexander Panfilov di FrontOps e Igor Antonov delle metriche di performance delle applicazioni web. Sono uscito con appunti pratici su tutti e tre gli argomenti.
La parte inaspettata è stata il Q&A. Alla fine ho vinto due premi per aver fatto le domande migliori durante le sessioni. È un dettaglio piccolo, ma è diventato il ricordo più forte della serata perché ha rafforzato il motivo per cui continuo ad apprezzare i meetup tecnici in presenza: puoi fare più che consumare una presentazione preparata. Puoi verificare la tua comprensione mentre le persone che hanno appena presentato l’argomento sono ancora nella stanza.
Il tema utile era la manutenzione, non la novità
Gli eventi frontend possono facilmente diventare una sfilata di nuovi framework, nuove API e nuove astrazioni. PiterJS #79 era più concreto. Il tema annunciato riguardava il supporto del software che esiste già.
È importante perché gran parte del lavoro di engineering avviene dopo il primo rilascio riuscito. Un monolite legacy non è automaticamente un cattivo sistema e “modernizzare” non significa automaticamente riscrivere tutto. La domanda pratica è di solito più precisa: quale vincolo sta facendo male al sistema oggi, e quale cambiamento riduce quel problema senza introdurre più rischio di quanto ne elimini?
È anche il motivo per cui i tre talk funzionavano bene insieme. Il refactoring cambia il codice. FrontOps cambia come il frontend viene costruito, impacchettato, distribuito e gestito. Il lavoro sulla performance cambia come misuriamo il risultato. Sono livelli diversi dello stesso problema: mantenere un sistema reale comprensibile e controllabile anche dopo che è cresciuto.
FrontOps è più ampio di un Dockerfile
Uno dei miei appunti dal meetup riguardava l’implementazione di FrontOps con Docker. La distinzione importante è che Docker è uno strumento, non la definizione di FrontOps.
La responsabilità frontend non finisce necessariamente quando npm run build va a buon fine. In produzione qualcuno deve ancora pensare a build riproducibili, packaging degli artefatti, configurazione, rollback delle release, comportamento della cache e osservabilità dei problemi. I container possono rendere parte di questo lavoro più prevedibile, ma non sostituiscono le decisioni operative.
È una correzione utile a un modello mentale comune: una build riuscita dimostra che la build si è completata. Non dimostra che l’applicazione verrà distribuita correttamente, che si comporterà bene in produzione o che sarà semplice recuperarla quando qualcosa andrà storto.
La performance parte dal decidere cosa significa “lento”
Il talk sulla performance era particolarmente pratico nel modo in cui inquadrava la misurazione. L’argomento annunciato includeva i fattori che influenzano la velocità di caricamento, diverse metriche di performance frontend, modi per quantificare il concetto di “lento” e perfino la domanda sul perché l’ottimizzazione non sia sempre necessaria.
Quest’ultimo punto è facile da sottovalutare. “Rendilo più veloce” sembra un obiettivo, ma senza una metrica e un problema visibile per l’utente può trasformarsi in costose supposizioni. Un processo di performance utile parte dal definire cosa sia davvero lento, misurarlo, individuare il collo di bottiglia, modificare una cosa rilevante e misurare di nuovo.
Una metrica non è da sola la user experience, ma dà alla discussione un’unità comune. Senza misurazione, il lavoro sulla performance può diventare una serie di cambiamenti tecnicamente impressionanti senza prove chiare che abbiano migliorato il problema che contava davvero.
Il Q&A ha cambiato il valore del meetup per me
Avrei potuto guardare le registrazioni e raccogliere i link più tardi. Quello che avrei riprodotto con più difficoltà era l’interazione intorno ai talk. Fare una buona domanda obbliga a comprimere un’incertezza in qualcosa di abbastanza specifico perché un altro engineer possa rispondere.
Vincere due premi è stato divertente, ma la lezione più utile era più semplice: arrivare preparati a partecipare dà a un meetup in presenza molto più valore che trattarlo come una playlist YouTube dal vivo.
Una buona domanda tecnica di solito contiene contesto e un vincolo. Invece di “Qual è l’architettura migliore?”, può essere più utile chiedere quale trade-off cambia se un team non può riscrivere un sistema legacy, se il deployment deve restare retrocompatibile o se una metrica migliora senza un beneficio equivalente visibile agli utenti.
Non significa che ogni domanda debba essere brillante. Significa che dovrebbe aiutare a far emergere assunzioni, limiti o failure mode.
Cosa porterei al prossimo meetup tecnico
- Sapere perché un talk mi interessa. Prima dell’inizio, scrivere un problema reale o un dubbio collegato al tema.
- Separare l’esperienza dello speaker dal mio sistema. Un buon case study è evidenza, non una ricetta universale.
- Chiedere dei trade-off. “Quando non lo useresti?” spesso rivela più di “Qual è lo strumento migliore?”
- Annotare una sola azione di follow-up. Una nota diventa più utile quando indica qualcosa da verificare, provare o leggere dopo il meetup.
- Non confondere un talk convincente con una prova in produzione. Le decisioni su architettura, deployment e performance devono comunque essere validate nel proprio ambiente.
Cosa mi è rimasto
Non voglio esagerare ciò che un singolo meetup può cambiare. Non sono uscito da PiterJS con una ricetta universale per l’architettura, e un buon talk non sostituisce documentazione, profiling, test o dati di produzione.
Quello che ho davvero portato via è più concreto: appunti utili sulla modernizzazione di un monolite legacy, su FrontOps con Docker e sulla misurazione della web performance; due premi dal Q&A; e un altro promemoria del fatto che vale la pena presentarsi di persona nelle community locali di sviluppatori.
Le registrazioni possono conservare la presentazione. La parte più difficile da archiviare è la conversazione che le sta intorno.