talk-phptour-2016

wallabag : comment on a migré vers Symfony 3

Par Jérémy Benoist (@j0k) et Nicolas Lœuillet (@nicosomb)wallabag.org

Nous deux

Jérémy Benoistlead developer chez 20minutes Nicolas Lœuilletdéveloppeur chez Smile

Plan

Historique
Etat des lieux
La migration
Les étapes en cours et à venir

Fonctionnalités et histoire

Ce que ça fait

wallabag est un read-it-later, une application de lecture différée : vous y stockez un article pour le lire plus tard, le contenu de l'article sera stocké et uniquement le contenu (wallabag supprimera tout ce qui est superflu, comme la publicité par exemple). Puisque wallabag existe en tant qu'application web et sur nos smartphones, vous retrouverez ces articles synchronisés automatiquement sur votre téléphone. D'autres fonctionnalités existent : les tags, les favoris, des filtres, de l'import depuis les services concurrents.

Histoire

En mars 2013, Google annonce la fermeture de l'un de ses services les plus populaires : Google Reader. À l'époque utilisateur de Pocket, un très bon service de read-it-later mais fermé et propriétaire, je me suis demandé ce que j'allais devenir si mon deuxième service préféré fermait du jour au lendemain. C'est ainsi qu'en avril 2013, poche, petite alternative sans prétention, est née. Rapidement, via le planet libre, quelques retours sont faits, quelques idées sont proposées. C'est à cette période que Thomas arrive. Janvier 2014, un tweet (https://twitter.com/wallabagapp/status/423786365944225792 ) est mal interprété par Pocket : ils nous contactent donc pour nous demander de : * changer de nom * changer de logo * ne plus utiliser le terme read it later (marque déposée) * ne plus dire qu'ils sont non free Brainstorming avec les utilisateurs de poche : un nouveau nom est trouvé, wallabag. Un logo est créé par une bénévole. Début 2015, on s'active vraiment pour la v2, avec l'arrivée de Jérémy dans l'équipe https://github.com/wallabag/wallabag/pull/1049 Première alpha, septembre 2015 v2 livrée le 3 avril 2016, trois ans jour pour jour après le tout premier commit.

Pourquoi ça n'était pas mieux avant

Première version de "wallabag"

Environnement PHP

PHP >= 5.3.3
Pas de framework
Des classes PHP de plusieurs centaines de lignes

Lacunes techniques

Dépendances versionnées
Pas d'API
Pas de tests
Pas de PR par l'équipe
MAJ BDD manuelle
Déploiement manuel via Filezilla 🙈
Équipe de deux personnes

34.000 téléchargements depuis déc. 2013

Fréquence des mises à jour

Pas de calendrier défini
10 versions mineures en deux ans
Pas de vrai respect de SEMVER

Versions correctives qui apportaient de nouvelles fonctionnalités, donc pas de SEMVER

Pourquoi c'est mieux maintenant

Deuxième version de wallabag

- Material UI - On n'est pas designer ...

Environnement PHP

PHP >= 5.5.9
Compatible PHP 7
Compatible HHVM (même si personne ne s'en sert)
Symfony 3

Grace à Symfony 3: contributions plus "simple" (plus cadré et plus connu)

On comble les lacunes techniques

Sorte de Definition of Done :
- Documentation utilisateur
- Tests unitaires et / ou fonctionnels
- Review du code
Déploiement via Capistrano (sur v2.wallabag.org)
Migrations BDD
Le moins d'actions manuelles possible
Équipe plus conséquente : une core team, des traducteurs, des développeurs

- Packaging, release, doc, etc. - Equipe de 20 personnes - 8 traducteurs - 3.600 téléchargements (depuis la première alpha) - 9.200 comptes sur Framabag (https://framabag.org/analytics/)

Fréquence des mises à jour

Roadmap établie
Respect de SEMVER
Une version mineure tous les 3 mois

- La fréquence rassure les gens - Prochaine version mineure le 3 juillet (les tags)

API pour les applications externes

Facilite l'intégration avec des applications tierces

Quelques benchmarks

Analyse du code

v1 v2 Fichiers 396 129 Code 94.922 lignes240 lignes / fichier 8.822 lignes68 lignes / fichier Commentaires 37.855 lignes 2.462 lignes Sensio Insight 29/1002 ans pour la médaille Platinum 32/1003 semaines pour la médaille Platinum Scrutinizer 4,95/10(1 erreur critique, +700 majeures) 9,39/10(4 erreurs majeures)

Chargement des pages

Analyses faites avec Blackfire sur PHP 7.0.6

v1 v2 Liste d'articles (460) 330ms17 Mo 689ms31 Mo Un article 89ms10 Mo 281ms17 Mo Liste des tags (20) 85ms10 Mo 314ms19 Mo

En conclusion ...

C'est pas très fameux pour la v2 tout ça !

Un framework, c'est lourd
Le plain PHP c'est forcément rapide
Pas trop focalisé sur la perf, pour le moment
Plusieurs pistes d'améliorations (Redis, APC, Blackfire, etc.)
Surtout un confort de développement pour les devs

En route pour la v2 !

Le choix du framework

Rapidement, (3 ou 4 mois après la toute première version de la v1), une refonte s'est fait sentir. Mais Nicolas n'avait pas les compétences pour se lancer dans le chantier tout seul. Plusieurs pistes : changement de technos, micro frameworks PHP, Symfony, etc. Une première ébauche de refonte avec Symfony a été démarrée avec Vincent Jousse, mais faute de temps, il a du quitter le projet. Puis est arrivé Jérémy

Extraction de contenu

LA principale fonctionnalité de wallabag
Assuré par Full-Text RSS, dans la v1
Pas vraiment open source ...
Et pas très pratique à utiliser ...

// $ftr should be URL where you installed this application
$ftr = 'http://example.org/full-text-rss/';
$article = 'http://www.bbc.co.uk/news/world-europe-21936308';

$request = $ftr.'makefulltextfeed.php?format=json&url='.$article;

// Send HTTP request and get response
$result = @file_get_contents($request);

- La principale fonctionnalité de wallabag, c'est l'extraction de contenu. - En v1: Full-Text RSS (première version open sourcé en 2011) - Pas vraiment open source, version la plus à jour payante mais versions précédentes gratuites. - Comme wallabag est open source, on ne peut pas utiliser la verion payante (ça rendrait son code open source ...). - En plus, ce n'est pas très pratique à utiliser ...

Extraction de contenu

MAIS, sa capacité d'extraction est efficace !
Utilise le microformat hNews
Utilise les données de Schema.org
Basée sur php-readability
Et sur des site_config (dans un repo séparé)

➜ Forker en gardant cette logique

- Full-Text RSS est très efficace dans ce qu'il fait, il se base sur des standards pour extraire les contenus. - L'idée était donc de faire un fork de Full-Text RSS en gardant ces fonctionnalités mais en le rendant plus facile à utiliser.

Extraction de contenu

graby, un fork de Full-Text RSS v3.3

Mise en place de test fonctionnels sur l'existant
Ré-organisation / refonte
site_config via Composer
Ajout de tests
Et c'est plus propre à utiliser ...

use Graby\Graby;

$article = 'http://www.bbc.co.uk/news/world-europe-21936308';

$graby = new Graby();
$result = $graby->fetchContent($article);

- Test fonctionnels sur l'existant pour valider la refonte - OptionResolver pour la configuration - Guzzle pour les appels cURL

La migration en soi

Par itération
- Le socle Symfony
- La connexion utilisateur
- La configuration
- La commande wallabag:install
- L'ajout d'un lien
- L'ajout de tags
- Etc.
Globalement, tout a été réécrit, étape par étape

La v2 n'est pas ISO avec la v1

v2.0.0 ➜ focaliser sur le fonctionnement de base v2.0.x ➜ focaliser sur la stabilité v2.x ➜ amélioration des fonctionnalités (tag, recherche, etc.)

Librairies utilisées pour l'API

FOSRestBundle
NelmioCorsBundle
FOSOAuthServerBundle
BazingaHateoasBundle
NelmioApiDocBundle

Si seulement API Platform 2.0 était sorti plus tôt :)

Listing des features par librairie

Utilisateur ➜ FosUserBundle
Filtres ➜ FormFilterBundle
Changement de thème ➜ LiipThemeBundle
Export ➜ phpepub, tcpdf, php-mobi
Règle de tagging ➜ RulerZ (😘 @KPhoen)
Maintenance ➜ MaintenanceBundle
Two factor authentication ➜ TwoFactorBundle
Annotations ➜ AnnotatorJS

Les difficultés

Installation de l'application

L'application doit être disponible pour tout le monde !

sur un serveur dédié
sur un serveur mutualisé
sur un ... raspberry (c'est pas gagné ...)

Et installable par tout le monde

"tout le monde" inclut des personnes novices

- Grosse contrainte d'utiliser un framework comme Symfony : - là où la v1 s'installe quasiment partout et très facilement, - la v2 va forcément devenir plus complexe à installer pour les débutants.

Installation de l'application

Deux solutions choisies :

Via une archive incluant les dépendances
Via Git & Composer

Installation de l'application

Plutôt basique pour la v1

wget http://wllbg.org/latest
unzip latest

+ quelques lignes de SQL

Dans l'ensemble aucun souci ✅

Installation de l'application

Tentative n°1

git clone https://github.com/wallabag/wallabag.git -b v2
cd wallabag
composer install
php app/console wallabag:install

Trop orienté dev
Installe toutes les deps "dev"
C'était bien au début ™

Installation de l'application

Tentative n°2

composer create-project wallabag/wallabag wallabag 2.0.0-alpha.1
cd wallabag
php app/console wallabag:install

Toujours trop orienté dev
Simple amélioration de la version précédente

Installation de l'application

Tentative n°3

SYMFONY_ENV=prod composer create-project wallabag/wallabag \
	wallabag "2.0.*@alpha" --no-dev
cd wallabag
php app/console wallabag:install --env=prod

Uniquement les packages de prod
MAJ impossible à cause de create-project

Installation de l'application

Tentative n°4 (l'actuelle)

git clone git@github.com:wallabag/wallabag.git
cd wallabag
git checkout 2.0.4
SYMFONY_ENV=prod composer install --no-dev -o --prefer-dist
php app/console wallabag:install --env=prod

Toujours bien en version de prod
Facilite la mise à jour (par les tags)
Mais toujours des soucis de mémoire

Autres difficultés

Les migrations de données SQLite
Les demandes de site_config
Les issues de personnes pas très techniques 😕

- Concernant SQLite, les migrations de base de données sont plus complexes : supprimer un champ avec SQLite n'est pas possible (il faut supprimer la table puis la recréer). - Toujours plus de SiteConfig - Toujours difficile d'isoler un souci

Les étapes en cours

RabbitMQ, pour les gros traitements
Elasticsearch (😘 @damienalexandre)
Dockerization par @JoliCode en salle C
Gérer les dépendances CSS et JS via

- Imports très gourmands en ressource - Timeout en pagaille - RabbitMQ pour l'instant, mais rien n'est encore réellement acté - Pour * import * action en masse sur les articles (refetch du contenu par exemple) - ES pour la recherche avancée ou de la recommandation

API : intégrations déjà réalisées

Trigger-Happy.eu : clone libre de IFTTT

- Automatisant la récupération de données sur le web, pour les posters dans wallabag via son API automatiquement. - Les données peuvent également provenir et être publiées depuis Twitter, Trello et plein d'autres services web existants.

API : intégrations déjà réalisées

Application Windows Phone (Android et iOS en cours de réalisation)
Addon pour Firefox
ttrss-to-wallabag-v2 : plugin pour ajouter dans wallabag depuis Tiny Tiny RSS
Librairies Python, Java et .NET

- Aujourd'hui, nos applications sont l'un des points faibles du projet : elles n'avancent pas au même rythme que l'application web - Certaines fonctionnalités attendaient l'API pour que l'on puisse les mettre en place. - Pour l'application Android, elle est compatible avec la v2 mais n'utilise pas encore l'API.

API : intégrations souhaitées

Cozy Cloud
ownCloud
Fabricants de liseuses
Firefox, Gnome (pour remplacer Pocket)

- Concernant Cozy Cloud ou ownCloud, la demande des utilisateurs devient de plus en plus forte. Nous sommes déjà en contact avec eux. - Pour les fabricants de liseuses, Nicolas a déjà rencontré il y a plusieurs mois un fabricant français, mais la discussion est restée en standby. - Si certains sont intéressés, qu'ils nous contactent.

Les étapes à venir

To infinity... and beyond

Un front en React
Une solution SaaS
Intégration dans des applis tierces
- Reeder
- IFTTT
- Etc.

- React ou autre chose - L'idée, c'est d'avoir une vraie application pour le front, qui utiliserait l'API. - Pas de SaaS pour la v2 (contrairement à la v1 avec Framabag). - Lancer un vrai SaaS de qualité est dans nos têtes. - Il ne nous manque que le temps pour mettre ça en place.

Merci !

Des questions ? 🤓

wallabag : comment on a migré vers Symfony 3 Par Jérémy Benoist (@j0k) et Nicolas Lœuillet (@nicosomb) wallabag.org

wallabag : comment on a migré vers Symfony 3 – Fonctionnalités et histoire – Pourquoi ça n'était pas mieux avant

nicosomb

wallabag : comment on a migré vers Symfony 3 – Fonctionnalités et histoire – Pourquoi ça n'était pas mieux avant

3 3 (function() { var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true; po.src = 'https://apis.google.com/js/platform.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s); })();