Nous vivons une ère d’excès numérique où les développeurs sont conditionnés à croire que le but d’une API est de servir des données. C’est une erreur fondamentale qui a coûté des milliards en infrastructure et en sécurité à travers le monde. Nous avons passé des années à débattre de REST contre GraphQL ou de gRPC contre WebSockets, en oubliant de regarder la solution la plus élégante et performante qui existe. Je parle du concept de No as a Service ou NaaS (https://github.com/hotheadhacker/no-as-a-service).
Pour ceux qui ont séché les cours de l’Académie de la Flotte Stellaire, le Kobayashi Maru est un exercice d’entraînement conçu comme un “scénario sans issue”. Le but n’est pas de gagner, c’est de voir comment vous gérez un échec inévitable. Dans le monde de l’ingénierie Backend, notre scénario sans issue est l’Exception Non Gérée.
Vous passez des semaines à concevoir un service beau et propre. Vous utilisez des Records, vous optimisez vos requêtes SQL, vous appliquez les principes SOLID. Et puis, le jour de la mise en production, un utilisateur envoie un JSON malformé, et votre API vomit une Stack Trace de 50 lignes directement dans la console de son navigateur. C’est moche, c’est peu professionnel, et cela expose votre logique interne au monde entier.
Si vous êtes un développeur qui a déjà géré du traitement de paie ou de la réconciliation bancaire/financière dans une entreprise utilisant Spring, vous avez probablement travaillé avec Spring Batch. J’avoue que je n’en suis pas un grand fan ; il a cette verbosité et cette lourdeur caractéristique de l’écosystème Java, donnant l’impression que même le job le plus simple nécessite bien plus de structure que nécessaire. Mais à quoi bon se plaindre ? La technologie que votre entreprise utilise est ce qui assure votre survie (logement, nourriture, vêtements). Donc, râler n’est pas le sujet du jour.
