La multi-location (multi-tenancy) en base de données désigne une architecture où une seule instance d’application et d’infrastructure sert plusieurs clients (tenants), tout en garantissant une isolation logique de leurs données. Ce modèle, largement adopté dans le cloud, permet une meilleure scalabilité, une réduction des coûts de maintenance et une optimisation des ressources. L’article détaille quatre approches principales : base unique avec schéma partagé (simple mais risqué en cas d’oubli de filtrage par tenant), base unique avec schémas séparés (meilleure isolation mais complexité accrue), base dédiée par tenant (isolation maximale mais coûteuse en gestion), et plusieurs bases avec tenants partagés (compromis entre coût et performance). Chaque méthode présente des avantages et des inconvénients selon les besoins en sécurité, performance et maintenance
L’article explique pourquoi l’auteur a abandonné Docker pour Podman, mettant en avant plusieurs avantages clés : Podman est sans démon, ce qui améliore la sécurité (moins de vulnérabilités liées à un processus root permanent) et réduit la consommation de ressources. Il s’intègre nativement avec systemd et Kubernetes, facilitant la gestion des conteneurs comme des services système et permettant une transition fluide vers des environnements de production. La migration est simple, car Podman utilise les mêmes commandes et fichiers Dockerfile que Docker, tout en offrant une approche plus sécurisée (mode rootless par défaut) et une meilleure alignement avec les pratiques Linux modernes. L’auteur souligne aussi que Podman encourage une architecture plus propre, comme l’utilisation d’un reverse proxy plutôt que l’exposition directe de ports privilégiés. En résumé, Podman se présente comme une évolution naturelle pour les développeurs cherchant plus de sécurité, de légèreté et de cohérence entre le développement et la production.
Un comparateur de distributions basées sur Android
L'article compare 2 manières de sérialiser des données : JSON et Proto (Protocol Buffer). Il conclue en donnant une règle : si des humains vont devoir lire les données échangées, préférer le JSON. Si ce sont des machins, préférer Proto.
L'article compare trois outils HTTP : Fetch API, Axios et Alova. Fetch API, intégré nativement dans JavaScript, est léger et idéal pour des requêtes simples mais nécessite une gestion manuelle pour des fonctionnalités avancées. Axios, bien que plus lourd, offre des fonctionnalités automatisées comme la gestion du JSON et des intercepteurs, le rendant adapté pour des applications complexes. Alova, quant à lui, combine la simplicité des requêtes avec des fonctionnalités avancées telles que la gestion de l'état et la mise en cache, ce qui en fait un choix optimal pour des applications front-end lourdes nécessitant une optimisation des performances.
Un comparatif des navigateurs (desktop, mobile) sur le respect de la vie privée
L'article explique ce qu'est un monolithe modulaire et quand il doit être préféré à une architecture de microservices.
Un article concis sur les différences entre WebSocket et Socket.IO pour la communication en temps réel
Un comparateur très complet sur les méthodes d'offuscation de mail
Tout est dans le titre
Une exploration de l'écriture d'un serveur HTTP minimaliste dans différents langages : Rust, Golang, Vlang, Ziglang, C et ASM
L'auteur expose des critiques envers bash, et pourquoi il se tourne à présent vers fish
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Une comparaison des deux build systems les plus utilisés dans Linux embarqué