Il tuo repo Bolt funziona: ma quante query servono per una pagina?

La scala non perdona le scorciatoie

GitHub ha dichiarato di gestire oggi circa 2,9 miliardi di commit al mese, 130 milioni di pull request unite e 24 milioni di nuovi repository. La crescita, alimentata anche dalla diffusione degli agenti di coding, ha contribuito a mettere sotto pressione la piattaforma: un componente infrastrutturale non è riuscito a scalare con il traffico e il problema si è propagato fino ai servizi di autenticazione.

La notizia è raccontata in GitHub now sees 2.9 billion commits a month — and it can’t keep up, pubblicato da The New Stack il 20 agosto 2026.

Il punto per te non è se il tuo prodotto abbia la dimensione di GitHub. È che lo stesso errore di scala può comparire in un SaaS appena lanciato: una pagina che sembra rapida con dieci record può diventare lenta quando ogni elemento genera una query separata.

Il buco tecnico di oggi è il problema N+1: una query per ottenere l’elenco, poi una query aggiuntiva per ogni riga restituita.

Cosa significa se il tuo codice l’ha scritto Bolt

Immagina una dashboard costruita con Bolt che mostra progetti, membri e ultimo evento. Il backend recupera i progetti con una query:

SELECT * FROM projects WHERE workspace_id = ?

Poi, mentre prepara la risposta, cerca il proprietario e l’ultimo evento per ogni progetto:

SELECT * FROM users WHERE id = ?
SELECT * FROM events WHERE project_id = ? ORDER BY created_at DESC LIMIT 1

Se la pagina mostra 50 progetti, quella che sembrava una singola operazione può diventare una query iniziale più 100 query aggiuntive. Con pochi dati, tutto sembra normale. Con più utenti, più richieste contemporanee e database condivisi, il tempo di risposta cresce e il database lavora molto più del necessario.

Bolt può aiutarti a costruire velocemente componenti, API e schermate collegate tra loro. Il rischio non nasce dal fatto che il codice sia stato generato da un agente. Nasce quando la relazione tra pagina, endpoint, ORM, resolver e database non viene verificata come un unico flusso.

Il percorso felice è convincente: apri la dashboard, vedi i dati, clicchi un progetto. Il percorso sotto carico è un’altra cosa. Quante query partono davvero? Quanti record vengono caricati? Cosa succede quando la lista passa da 10 a 1.000 elementi? Esistono paginazione, filtri e limiti? La risposta include dati che la UI non usa?

Un’app può quindi essere corretta dal punto di vista funzionale e avere comunque una scalabilità fragile.

Perché ora ti serve un audit: il problema è nel percorso completo

Un audit tecnico serve a trasformare “la pagina è abbastanza veloce” in un verdetto sul comportamento effettivo del repository.

Per il problema N+1, l’analisi deve seguire il dato dall’ingresso alla risposta:

• quale endpoint alimenta la pagina;
• quale query principale recupera la collezione;
• quali funzioni vengono eseguite durante il ciclo sui risultati;
• quali relazioni vengono caricate una alla volta;
• se l’ORM applica lazy loading o resolver ripetuti;
• se esistono query duplicate tra componenti, serializer e middleware;
• se la paginazione limita davvero sia i risultati sia il lavoro del database;
• se export, ricerca e ordinamento usano percorsi più costosi della schermata principale.

L’obiettivo non è soltanto trovare una query lenta. È capire se il numero di query cresce insieme al numero di elementi restituiti. Se raddoppiando i record raddoppiano — o quasi — anche le query, hai un segnale concreto di N+1.

Un audit VibeInspect analizza il repository ZIP e produce un PDF con score, verdetto ed evidenze. Nel piano Diagnostic, il risultato può collegare il problema ai file e alle righe coinvolte: il controller che carica la lista, il serializer che accede alla relazione, il resolver che ripete la chiamata o il componente che richiede dati uno per volta.

Questo è il passaggio che spesso manca dopo aver spedito con Bolt. Hai una demo, magari un test end-to-end e una risposta corretta. Non hai ancora una misura indipendente della complessità del percorso dati.

Per un sospetto tecnico già definito, come un N+1, il piano coerente è Diagnostic. Non applica fix e non include una revisione umana ordinaria: ti consegna però le evidenze necessarie per decidere dove intervenire.

Un audit deve guardare anche ai fallback

Il problema non è sempre visibile nella query principale. Può apparire in un fallback o in una funzione secondaria.

Una pagina può caricare i progetti in blocco ma recuperare separatamente avatar, conteggi, permessi o ultimo aggiornamento. Un endpoint può essere efficiente per la tabella principale ma diventare costoso quando viene usato per una ricerca libera. Un job asincrono può ripetere la stessa query per ogni elemento senza che il rallentamento compaia nella UI.

Per questo il verdetto deve considerare i percorsi che condividono la stessa risorsa: pagina, API, export, notifiche e processi in background. La domanda non è “esiste una query ottimizzabile?”. La domanda è “il costo cresce in modo prevedibile quando cresce il numero di elementi?”.

Un risultato utile dovrebbe anche distinguere tra rischio teorico e rischio osservabile nel codice. Un ciclo su una lista non è automaticamente un N+1: dipende da cosa viene chiamato dentro quel ciclo. Allo stesso modo, una query con molte righe non è necessariamente un problema se usa un limite, un indice e una forma di caricamento appropriata.

Il valore dell’audit sta proprio nel separare questi casi e nel produrre un verdetto leggibile, non una lista generica di possibili ottimizzazioni.

Cosa un linter non vede

Un linter può individuare variabili non usate, errori di sintassi, import inutilizzati, tipi incoerenti e alcuni pattern locali. È utile per mantenere il codice più pulito.

Non può però capire da solo che una funzione chiamata dentro un ciclo esegue una query al database per ogni elemento. Non conosce sempre il comportamento runtime dell’ORM, la cardinalità delle relazioni o la differenza tra una query eager e una lazy.

Un linter non misura automaticamente il numero di query per richiesta, la latenza al crescere dei record o il carico generato da richieste concorrenti. Non sa se la pagina usa 20 campi dopo averne caricati 200. Non sa se un export ignora la paginazione e tenta di materializzare l’intero workspace in memoria.

Anche una suite di test verde non basta. Un test con tre progetti può confermare il risultato senza mostrare che l’endpoint esegue sette query invece di due. Il test dimostra che l’output è corretto; non dimostra che il costo sia sostenibile.

La performance è una proprietà del sistema in esecuzione, non soltanto del testo del codice.

Cosa fare questa settimana

Se hai spedito con Bolt, parti da una singola pagina che legge dati dal database.

1. Scegli una dashboard o una lista usata spesso.
2. Misura il numero di query per una risposta con 10, 50 e 100 elementi.
3. Controlla cosa succede dentro i cicli che costruiscono la risposta.
4. Cerca accessi a relazioni, conteggi o dettagli eseguiti uno per volta.
5. Verifica che paginazione e limiti siano applicati lato database, non soltanto nella UI.
6. Ripeti la misura su ricerca, ordinamento, export e job asincroni.
7. Controlla i fallback: dati mancanti, avatar, permessi e ultimo evento sono spesso caricati separatamente.
8. Registra query, latenza e dimensione della risposta in un caso realistico.
9. Aggiungi un test che fallisca se il numero di query cresce oltre una soglia definita.
10. Confronta il risultato con il comportamento atteso prima di ottimizzare.

“Funziona con dieci record” non è un verdetto. “La pagina mantiene un numero di query controllato, usa paginazione e il costo non cresce una volta per ogni elemento” è un verdetto.

Se non sai ancora dove si trova il collo di bottiglia, puoi partire da VibeInspect.ai con Snapshot. Se hai già notato query ripetute, resolver lenti o tempi che peggiorano con la dimensione della lista, scegli Diagnostic per ottenere evidenze su file, righe e flussi.

Bolt ti ha aiutato a trasformare un’idea in un prodotto. Prima che il traffico trasformi ogni riga in una nuova query, assicurati di sapere quanto costa davvero una richiesta.