L'article de Jay Freestone propose une approche pour éviter la duplication des règles métier entre frontend et backend en privilégiant le partage de politiques plutôt que de code. L'idée centrale est que les règles, comme la validation d'état d'une commande, doivent être centralisées côté serveur pour éviter des incohérences lorsque les deux parties évoluent indépendamment. Plutôt que de partager des fonctions ou des modules (risquant des divergences de versions ou de déploiement), l'auteur suggère de transmettre les décisions sous forme de données structurées, comme les actions autorisées ou les raisons de désactivation, permettant au frontend de s'adapter dynamiquement.
L'auteur illustre cette méthode avec un exemple concret : au lieu de dupliquer une fonction canCancelOrder en TypeScript à la fois dans l'API et l'interface, le backend renvoie un objet JSON contenant les actions possibles (allowedActions) et les motifs de désactivation (disabledReasons). Cette approche, inspirée des principes HATEOAS, simplifie la maintenance et garantit la cohérence des règles, tout en restant compatible avec des architectures polyglottes où le partage de code est complexe.
Améliorez le temps de réponse du serveur (TTFB) et l'expérience utilisateur (UX) grâce au streaming HTTP. Cet article explique comment le streaming HTTP peut accélérer la perception de la vitesse de chargement des pages dynamiques en envoyant progressivement le contenu au navigateur, plutôt que d'attendre que toute la page soit générée. Cela est particulièrement utile pour les pages affichant de nombreuses lignes de données. L'article fournit un exemple en JavaScript/TypeScript utilisant le framework Mastro et Kysely pour la base de données, démontrant comment utiliser le streaming pour améliorer les performances.
L'article explique pourquoi une entreprise a migré son backend de Python à Node.js seulement une semaine après son lancement. Malgré les conseils habituels de ne pas s'inquiéter de l'échelle au début, ils ont choisi de le faire pour des raisons de scalabilité. L'auteur, un fan de Django, a rencontré des difficultés avec le code asynchrone en Python, trouvant la mise en œuvre complexe et peu intuitive. Il attribue ces problèmes aux fondations instables de l'asynchrone en Python, contrairement à des langages comme JavaScript ou Go qui l'ont intégré dès le départ. Des articles de blog récents ont confirmé ces observations. L'expérience a révélé plusieurs limitations, comme l'absence de support natif pour l'E/S de fichiers asynchrones, le manque de support complet pour l'asynchrone dans Django, et la nécessité de convertir constamment entre code synchrone et asynchrone. Ces défis ont finalement conduit à la décision de migrer vers Node.js.
Les states (états) de Terraform représentent un instantané de l'état de l'infrastructure gérée. Ils permettent de maintenir la cohérence et la fiabilité de celle-ci. L'auteur présente les backends pour enregistrer les états (avec un exemple pratique sur S3), le dépannage et les bonnes pratiques.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre