DES PONEYS À LIBÉRATION.FR
Mathieu 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 (2)
Dans project/settings.py :
WIKIMODEL = 'mywikimodel'
WIKIAPPNAME = 'libe'
Dans wikiapp/__init__.py :
from django.db.models.loading import getmodel
from 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