Que faire lorsque des problèmes de performances apparaissent dans une application Django et que l'on arrive aux limites du modèle relationnel. Plus important, peut-on vraiment se passer du modèle relationnel et tout migrer vers des bases de données NoSQL.
Cette présentation a pour but de montrer sur un cas réel, avec un projet Django historique usuel, comment améliorer les performances et mettre en place simplement et au fur et à mesure une architecture permettant de prendre du recul et de siloter son application pour la rendre plus efficace.
L'architecture CQRS, pour Command Query Responsibility Segregation, ne vend aucune technologie ou langage, elle permet de prendre un autre point de vue sur son application et différencie/ségrégue les lectures des écritures.
Le cas réel utilisé sera celui du site web APPARTINFO.com basé sur Django/GeoDjango et PostgreSQL, le but de ce site est de rassembler Points d'Intérêts géolocalisés et commentaires d'anciens locataires/propriétaire pour créer une fiche d'identité complète d'une adresse sur le territoire français.
De nombreux calculs de distance et de lourdes requêtes entrent en jeu lors de l'affichage d'une page et ceux-ci, dans un environnement normalisé, deviennent rapidement handicapant pour les perfs.
L'idée sera donc de montrer, théoriquement et pragmatiquement, code à l'appui, comment reprendre une architecture Django classique et la transformer en archi CQRS en utilisant des outils existant et fiable, et ce sans avoir à reprendre toute l'application en une seule fois.