des poneys à liberation.fr
TRANSCRIPT
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