Produit
Modèles Adios pour applications, API, bases de données, caches et files d’attente
Le catalogue dépasse désormais quelques modèles d’applications. Il réunit applications web, API, bases de données, caches et files d’attente au même endroit.
Un modèle utile doit vous épargner la configuration initiale sans masquer les décisions dont vous serez ensuite responsable. C’est le principe qui guide l’élargissement du catalogue Adios.
Commencer par la nature du workload
Le catalogue s’organise désormais autour de trois points de départ pratiques : applications web, modèles d’API et services de données. Vous pouvez commencer avec Next.js ou un site Nginx statique, choisir un framework d’API en Node.js, Python, Ruby, PHP, Go ou .NET, ou associer un service comme PostgreSQL, Redis, MongoDB, MySQL ou RabbitMQ.
Chaque entrée présente ses variantes plutôt que de les réduire à un nom de framework générique. Le gestionnaire de paquets, le langage, le dépôt autonome et la clé de déploiement restent visibles avant tout lancement.
Le manifeste fait partie du modèle
Chaque modèle complet comprend un fichier adios.yaml. Il indique l’environnement d’exécution, les commandes de compilation et de démarrage, le port et les volumes persistants nécessaires au workload. La configuration du déploiement peut ainsi être examinée avec le code applicatif.
Vous obtenez un projet de départ que vous pouvez inspecter localement, modifier dans un workflow Git classique et déployer avec la configuration que vous avez examinée.
- —Examinez package.json et la commande de démarrage en production.
- —Confirmez que le service écoute sur le PORT configuré à l’adresse 0.0.0.0.
- —Appelez la route de contrôle de santé avant d’ajouter du code applicatif.
- —Versionnez le premier changement métier séparément de la configuration du modèle.
git clone https://github.com/adiosdotdev/template-node-fastify.git
cd template-node-fastify
adios upLes modèles sont un point de départ
Le catalogue rassemble délibérément de petits projets compréhensibles. Il ne cherche pas à prédire votre modèle métier ni à remplir le dépôt de fonctionnalités que vous supprimerez. Il donne au framework une commande de production, un chemin de contrôle de santé si nécessaire et assez de structure pour commencer le vrai travail.
Choisissez l’environnement d’exécution le plus proche de vos besoins, déployez-le, puis adaptez-le. L’intérêt est de partir d’une configuration qui fonctionne déjà.
Ajouter délibérément la gestion d’état
Si le récepteur de webhooks exige une déduplication, ajoutez PostgreSQL pour conserver durablement les identifiants d’événement, ou Redis pour une courte fenêtre d’idempotence, selon la garantie requise. Le catalogue propose les deux, mais le modèle du framework ne choisit pas discrètement à votre place.
Par exemple, un webhook de paiement qui ne doit jamais être appliqué deux fois doit être enregistré dans une table durable avec un identifiant d’événement du prestataire unique. Un cache peut réduire le travail répété, mais ne doit pas être la seule trace d’un événement financier.