Talks and workshops about frontend architecture and delivery at scale.

La Dependency Injection (DI) è un pattern fondamentale per sviluppare software manutenibile, scalabile e facilmente testabile. Tuttavia, viene spesso associata a framework pesanti e a un’infrastruttura runtime complessa. Dal punto di vista della filosofia Lean Web, sorge quindi una domanda semplice: è possibile mantenere i vantaggi della Dependency Injection restando il più possibile vicini alla piattaforma web?

Questo intervento esplora come la metaprogrammazione, e in particolare gli ECMAScript Decorators, renda possibile un approccio alla Dependency Injection basato esclusivamente su JavaScript Vanilla. Verrà presentata una panoramica dell’attuale proposta dei Decorators del TC39 (attualmente allo Stage 3), con un approfondimento dedicato ai Parameter Decorators (attualmente allo Stage 1).

Attraverso una dimostrazione pratica, vedremo come realizzare un contenitore minimale di Inversion of Control (IoC) in linea con i principi del Lean Web, definendo servizi iniettabili tramite un decoratore personalizzato e annotando i parametri dei costruttori per raccogliere i metadati necessari alla risoluzione delle dipendenze.

L’obiettivo è mostrare come le future funzionalità di ECMAScript rendano possibile implementare una Dependency Injection pulita e dichiarativa sfruttando direttamente le capacità della piattaforma, senza dover ricorrere a framework complessi.

Ogni volta che inizi una nuova sessione assistita dall’AI, i tuoi agenti partono da zero. Non ricordano la decisione architetturale presa la settimana precedente. Non sanno perché hai scelto un determinato pattern tre progetti fa. Non sono consapevoli che la sessione precedente si è interrotta prima che il lavoro fosse completato. Così ti ritrovi a spiegare tutto da capo.

La context engineering è la disciplina che risolve questo problema: stabilisce quali informazioni gli agenti devono conoscere, quando devono conoscerle e come queste conoscenze possano sopravvivere ai confini tra una sessione e l’altra e ai cambi di strumenti. È un concetto distinto dalla prompt engineering e, probabilmente, rappresenta la competenza con il maggiore impatto quando si sviluppano applicazioni basate su agenti AI.

In questo intervento verranno presentate le tecniche alla base della memoria persistente per gli agenti AI: il caricamento index-first, la sintesi iterativa ancorata (anchored iterative summarization) e il caricamento del contesto basato sulle fasi (phase-based context loading). Verranno inoltre illustrate le decisioni architetturali che hanno portato a queste soluzioni e spiegato perché, alla fine, l’approccio corretto si è rivelato molto più semplice di quanto ci si potesse aspettare.

Le applicazioni Angular stanno diventando sempre più intelligenti. Gli agenti AI stanno iniziando a pilotarle, ma nessuno ha ancora definito con chiarezza come questo debba funzionare in un ambiente di produzione. Questo intervento esplora una possibile risposta.

Quando un agente deve restituire qualcosa di interattivo, come un modulo, una dashboard o una tabella di dati, generare HTML o JSX è una soluzione poco sicura e impossibile da validare oltre un confine di fiducia (trust boundary).

A2UI è lo standard aperto di Google per la comunicazione tra agenti e interfacce utente: gli agenti producono JSON dichiarativo, l’applicazione Angular mantiene il controllo del rendering attraverso il proprio catalogo di componenti e l’agente non esegue mai codice nel browser. Si scopre che i punti di forza già esistenti di Angular (Signals, componenti standalone e rilevamento delle modifiche senza Zone.js, Zoneless change detection) si adattano quasi perfettamente a ciò di cui questo protocollo ha bisogno. E non è una coincidenza.

Vedremo come gli schemi di catalogo definiti con Zod guidino sia la validazione lato client sia i vincoli imposti alla generazione da parte dell’agente, come il modello di aggiornamento in streaming di A2UI si integri con la reattività granulare dei Signals e perché il modello di rendering Zoneless sia quello più adatto per interfacce guidate da agenti. Parleremo anche, senza nascondere i limiti, di ciò che il framework gestisce automaticamente e di ciò che dovrete invece implementare voi.

La dimostrazione consiste in una dashboard aziendale controllata da un agente AI in tempo reale. Al termine dell’intervento avrete chiaro perché un Angular “AI-native” non richiede un nuovo framework: è semplicemente quello che già conoscete, utilizzato nel modo corretto.