Se usi Effect, aggiungere Alchemy significa smettere di “collegare a mano” risorse cloud e codice: stack, deploy incrementali e riferimenti tipizzati nello stesso progetto.
Costruire applicazioni web oggi significa spesso gestire due mondi che si parlano male: codice applicativo da una parte e infrastruttura dall’altra. Anche quando usi strumenti moderni, ti ritrovi facilmente con configurazioni separate, nomi da ricordare, risorse da creare prima “da qualche parte” e collegamenti da mantenere coerenti nel tempo.
Alchemy prova a risolvere proprio questo: ti permette di descrivere e distribuire l’infrastruttura scrivendo TypeScript, integrandosi con Effect per rendere il tutto più strutturato, tipizzato e — soprattutto — difficile da rompere per distrazione.
Il problema: configurazioni scollegate e passaggi manuali
Prendiamo un caso comune: distribuire un’app su Cloudflare Workers.
Cloudflare già fa molte cose bene: tipicamente definisci worker e risorse in un file di configurazione (es. wrangler.jsonc), specificando entrypoint, binding e dipendenze (come bucket di object storage, KV, D1, ecc.). È già un approccio “infrastructure as code”.
Ma nella pratica emergono due attriti:
- Le risorse vanno create comunque: il bucket, ad esempio, potresti doverlo creare dal dashboard o via CLI prima del deploy.
- Il collegamento è fragile: nomi e riferimenti devono combaciare perfettamente tra configurazione, risorse create e codice. Un refuso e il deploy fallisce, oppure peggio: punta alla risorsa sbagliata.
Questa frizione aumenta quando:
- lavori su più ambienti (dev/stage/prod),
- automatizzi con CI/CD,
- deleghi parte del lavoro a tool/agent automatizzati,
- il progetto cresce e “solo un bucket” diventa “20 risorse collegate”.
Cos’è Alchemy (in pratica)
Alchemy è una libreria che ti fa definire infrastruttura e deployment come programma TypeScript. L’idea chiave non è “un altro formato di config”, ma:
- scrivi TypeScript per descrivere risorse e dipendenze,
- organizzi tutto in stack (collezioni di risorse che appartengono allo stesso dominio/app),
- esegui il deploy via CLI e Alchemy usa uno state per capire cosa è già stato distribuito e applicare solo le differenze.
Questa parte — deploy incrementali basati su stato — non è nuova nel mondo IaC (Terraform & co. insegnano). La differenza importante è il come: qui la fonte di verità è codice TS con un modello composizionale.
Perché la combo con Effect cambia il gioco
Alchemy “abbraccia” Effect: significa che il modo in cui definisci ed esegui parti dell’app (e spesso anche l’infrastruttura) segue regole più rigide e prevedibili.
Senza entrare in filosofia, l’effetto concreto per un team frontend/fullstack è:
- più guardrail: flussi chiari, composizione esplicita, meno “magia”;
- type safety reale tra risorse e codice che le usa;
- integrazione naturale tra logica applicativa e provisioning.
Il punto forte è proprio quest’ultimo: l’infrastruttura non è più un “satellite” attorno al progetto, ma un pezzo del progetto.
Stack: un’unità coerente di risorse
In Alchemy lavori per stack: una stack è semplicemente un contenitore di risorse che “stanno insieme”. Un’app potrebbe essere una stack; un monorepo potrebbe averne più di una.
Dentro una stack:
- scegli un provider (non solo Cloudflare: anche AWS, Fly, Hetzner, e altri che evolvono rapidamente),
- definisci uno state (dove Alchemy salva cosa è stato deployato),
- componi risorse e dipendenze.
Il fatto che supporti molti provider è utile, ma il vero vantaggio è che il modello resta lo stesso: impari un linguaggio mentale, non una dashboard.
Il salto di qualità: risorse e codice nello stesso grafo di dipendenze
Immagina di avere:
- un worker che risponde a richieste HTTP,
- un bucket per salvare documenti (upload, asset, log, ecc.).
Nel flusso tradizionale:
- crei il bucket (dashboard o comando CLI),
- lo “bindi” al worker in config,
- ti assicuri che nomi e binding coincidano,
- nel codice accedi al binding con la stringa corretta.
Con Alchemy, il bucket può diventare una risorsa definita in TypeScript, esportata insieme al worker, e la stack la importa come dipendenza. Risultato:
- niente passaggi manuali per creare la risorsa;
- niente stringhe da sincronizzare tra mille file;
- Alchemy capisce le relazioni (worker → usa bucket) e crea/applica ciò che serve nel giusto ordine;
- il collegamento diventa un riferimento tipizzato nel tuo progetto.
Questo riduce drasticamente quella categoria di bug “banali” ma costosi: nomi sbagliati, risorse non create, binding non aggiornati.
Non è solo hosting: infrastruttura “attorno” al codice
Alchemy non si limita a “dove gira il worker”. Il suo obiettivo è essere la cassetta degli attrezzi per descrivere ciò che serve attorno alla tua applicazione:
- provider di compute (worker/lambda-like),
- storage,
- database (anche non legati al provider principale),
- utility per workflow e tooling (CLI, container, ecc.).
In pratica: ti avvicina all’idea di progetto auto-consistente, dove il repo contiene sia la logica di business sia la definizione riproducibile dell’ambiente in cui quella logica vive.
Implicazione pratica per chi sviluppa (anche frontend)
Se lavori su prodotti web, soprattutto in TypeScript, i vantaggi non sono “da DevOps”: sono quotidiani.
- Setup nuovi ambienti più rapidi: meno checklist e meno “passami il nome del bucket”.
- Refactor più sicuri: se una risorsa cambia, la dipendenza è nel codice e non dispersa in configurazioni testuali.
- Deploy più affidabili: lo state permette aggiornamenti incrementali e riduce la necessità di operazioni manuali.
- Meno distanza tra chi scrive UI/feature e chi gestisce runtime/risorse: tutto nello stesso linguaggio.
Sintesi e conclusione
L’infrastructure as code non è una novità. La novità, qui, è farla diventare parte organica del progetto TypeScript, con un modello che unisce risorse, dipendenze e logica applicativa in modo tipizzato e composizionale.
Se già usi Effect, Alchemy è un passo naturale: sposta l’infrastruttura da “config + dashboard + rituali” a “codice versionato e verificabile”, riducendo errori di collegamento e rendendo il deploy un’estensione coerente del tuo sviluppo. In un ecosistema in cui i progetti crescono velocemente e l’automazione è la norma, questo approccio smette di essere un vezzo e diventa un vantaggio competitivo concreto.
Articolo originale: https://frontendfacile.it/blog/alchemy-infrastruttura-as-code-in-typescript-davvero-integrata-con-la-tua-app
Top comments (0)