Il team di Gadget condivide il proprio resoconto di esperienza dopo diversi giorni di sviluppo intensivo sul nuovo ChatGPT Apps SDK di OpenAI. L'articolo dettaglia i tre componenti essenziali di un'applicazione ChatGPT: un MCP server conforme al Model Context Protocol, un'estensione che consente di visualizzare interfacce utente all'interno delle conversazioni e, facoltativamente, un server OAuth 2.1 con OIDC per l'autenticazione.
Per la costruzione di MCP server, l'articolo raccomanda di utilizzare il trasporto Streamable HTTP piuttosto che la versione SSE presentata negli esempi ufficiali di OpenAI. Gli esempi forniti utilizzano una mappa di sessione in memoria non adatta alle piattaforme serverless. L'MCP Inspector è consigliato per il debug iniziale, poiché i messaggi di errore di ChatGPT sono poco informativi.
L'implementazione dell'autenticazione OAuth 2.1 rappresenta un cambio di paradigma: contrariamente alla pratica abituale di reindirizzare verso un provider esterno come Google, qui è l'applicazione stessa a dover fungere da provider OAuth per OpenAI. Ciò richiede l'implementazione degli endpoint di discovery OIDC che consentono a ChatGPT di ottenere i token.
La funzionalità più innovativa è la possibilità di servire agli utenti widget UI interattivi. Questi widget sono in realtà iframe sandboxed che caricano un documento HTML statico, messo in cache al momento dell'installazione dell'applicazione. Questo vincolo impone lo sviluppo di single-page application lato client, senza rendering dinamico lato server. Il team raccomanda Vite per la compilazione TypeScript, il bundling, l'hot-module-reloading e il supporto Tailwind. Un plugin Vite dedicato è disponibile su GitHub.
Per la comunicazione con il backend da un widget esistono due approcci. L'oggetto window.openai iniettato da OpenAI consente di chiamare gli strumenti MCP con l'autenticazione gestita automaticamente e visibilità per l'LLM sulle interazioni. L'alternativa tramite fetch diretto richiede la gestione manuale dell'autenticazione e perde la consapevolezza contestuale dell'LLM.
Il CORS rappresenta una sfida importante, con tre configurazioni distinte da gestire: le route MCP, le route OAuth 2.1 e gli asset frontend. Per le prime due, si raccomanda un header permissivo Access-Control-Allowed-Origin: *, poiché l'autenticazione già protegge le chiamate. Per gli asset dei widget, deve essere consentita l'origine https://web-sandbox.oaiusercontent.com utilizzata da OpenAI.
L'articolo conclude che l'ecosistema è ancora molto giovane ma promettente, con template pronti all'uso disponibili presso Gadget per accelerare l'avvio.