DES PONEYS À LIBÉRATION.FRMathieu Pillard Yohan Boniface

Rencontres django-fr, 16 avril 2011

Introduction

● Projet lancé en décembre 2009● Équipe très réduite (au départ, 2 personnes, ne

connaissant ni python ni django :-)● Toute une (double) plateforme vieillissante (en

PHP) et couteuse en place, à maintenir en parallèle du remplacement

● Migration le plus possible brique par brique

État des lieux aujourd'hui

● On est loin d'avoir fini● On utilise django pour :

● Next.liberation.fr (2 millions de pages vues/mois)● La recherche front (300.000 pages vues/mois)● La « liseuse » du journal papier sur le web (1 million de pages vues/mois)● L'API pour accéder à nos données (30 millions de requêtes / mois)● De la pub et autres trucs divers

● Architecture ultra-simple car besoins ultra-limités :● Un frontal, une base de données, et un gros CDN devant qui cache tout

pour nous

Migration et synchronisation

● Le “back”, où sont créées les données, n'est pas encore en django

● Du coup, on synchronise les changements vers notre architecture django en quasi-live

● Fonctionnement :● Triggers SQL sur toutes les anciennes tables● Créé des entrées en base dans created/updated/delete_rows● Vérifié toutes les minutes par un démon● Table de correspondance anciens modèles <=> nouveaux modèles● Synchro des fichiers via un autre démon

● On ne synchronise que dans un sens, pas question d'avoir 2 endroits qui écrivent en même temps

● Gère entre 5.000 et 25.000 update/delete/inserts en base par jour

API

● On utilise piston – pratiquement le seul choix abouti au moment de la mise en place il y a un an

● On est à peu près REST, mais on triche : c'est du read-only● On aime :

● Relative simplicité● Rapide à mettre en place

● On aime pas :● Pas facile de sortir des clous● Peu maintenu – c'est en train de changer, un « community fork »

est en train de se mettre en place

Des petites applis par milliers

● But : refaire notre zone “communautaire” en django - reproduire les fonctionnalités existantes

● Idée : profiter de l'écosystème d'applications django existantes

● Applications séparées plutôt que Pinax● Pinax est orienté “clé en main”, pas adapté pour notre besoin● La 0.9 se fait toujours attendre...

● Forks de quasi-toutes les applis concernées (~ une douzaine) sur https://github.com/liberation● Réactivité tout en gardant un contrôle● Rajoute de fonctionnements qui nous manquent et re-versement des

changements à la communauté

● Presque tout est fait, mais pas encore en prod, les priorités ont changé en cours de route :-)

La slide qu'on(g) savait pas ou la mettre(et j'ai pas pensé à proposer le sujet de conf assez tôt)

● La super appli de la mort qu'on adore : django_compressor● Gère la concaténation, minification etc de vos fichiers css/js

automatiquement● Transparent pour les développeurs, juste des templatetags à

rajouter dans les templates, pas de settings compliqués à ajouter● Commandes de management optionnelles pour remplir le cache

en une fois au lieu de générer en live● Gère automatiquement les modifications, suffixage pour les

caches, etc● Bien maintenu, documenté et testé

Minute philosophique: machine à café ou boîte à outils?

● Beaucoup d'applis django sont construites en mode « plug&play »● Très avantageux pour des petits sites, génériques, rapidement● Beaucoup plus compliquer pour intégrer les fonctionnalités dans une

modélisation déjà existante et plus exigeante

● Pistes:● Restreindre le périmètre des applis, les contenir à des fonctionnalités

cohérentes● Éviter d'imposer une modélisation (donner le choix du modèle/manager via des

settings, et proposer des classes abstraites de base)● Ne pas tenter de gérer la glue entre les applis à l'intérieur des applis (utiliser les

signaux, laisser les développeurs les utiliser)

Exemple d'appli générique qu'on aimerait voir plus souvent (1)

Exemple d'appli générique qu'on aimerait voir plus souvent (2)Dans project/settings.py :WIKIMODEL = 'mywikimodel'WIKIAPPNAME = 'libe'

Dans wikiapp/__init__.py :from django.db.models.loading import getmodelfrom django.conf import settings

def get_model():appname = getattr(settings, 'WIKIAPPNAME', 'wikiapp')model = getattr(settings, 'WIKIMODEL', 'WikiModel')return getmodel(appname, model)

Et ensuite, utilisation de wikiapp.get_model() partout au lieu de WikiModel. Le projet implémentant l'application peut utiliser sa propre modélisation, rajouter des champs, méthodes, etc

Conclusion, futur

● On pensait avoir fini vite, c'était sans compter les autres projets à développer, l'ancienne plateforme à maintenir...

● Prochaines étapes :● Finir la partie news● Finir la partie communautaire● Finir de mettre en place une vraie architecture● Ça fait beaucoup de finir, mais ca devrait être prêt en septembre

si tout va bien● Une fois que tout est la, un back-office propre coté django