À propos du projet

Alchemy se décrit comme « Infrastructure-as-Effects » : l'infrastructure cloud et la logique applicative écrites comme un seul programme Effect typé. Au lieu de séparer la configuration de l'infrastructure du code d'exécution, les ressources, les Workers/Lambdas, les politiques IAM et les appels SDK vivent dans le même programme, sans YAML et sans second runtime. Idées clés du README : - Un programme, un langage : les ressources, les fonctions, IAM et les SDK partagent le même programme Effect. - Des bindings au lieu de code de collage : un appel tel que S3.GetObject(bucket) est censé câbler la politique IAM, la variable d'environnement et un appel SDK typé en une seule ligne. L'exemple montre Cloudflare.R2.ReadWriteBucket(Bucket) connectant un binding, une variable d'environnement et un client typé à la fois au moment du déploiement et à l'exécution. - Les erreurs dans le système de types : les défaillances des API cloud sont représentées comme des erreurs Effect taguées pouvant être traitées délibérément. - Couverture des fournisseurs aujourd'hui : AWS (S3, SQS, DynamoDB, Kinesis, Lambda, EC2) et Cloudflare (Workers, R2, D1, Durable Objects, Containers). - Le même code à travers les étapes : le développement local, le plan/déploiement, les smoke tests et la CI sont présentés comme partageant un même modèle mental. L'installation est indiquée comme `bun add alchemy@latest effect@rc`. Une GitHub Action racine peut déployer `prod` depuis `main`, déployer les aperçus de PR en tant que `staging-{number}`, et détruire les aperçus lorsqu'une PR est fermée ; le workflow doit installer la CLI alchemy avant l'exécution de l'action. Le README fournit également un prompt pour les agents de codage IA qui récupère un index de documentation llms.txt, ainsi que des liens vers un tutoriel, des exemples et Discord. Le projet indique qu'il est en alpha et que des changements cassants doivent être attendus. Il est sous licence Apache 2.0, avec les licences tierces documentées séparément.