Ou comment refuser les caprices d’une base de données legacy qui se comporte comme une princesse.

Le contexte

En janvier 2015, KNP a été missionné par la start-up iPocrate pour assurer le développement de sa nouvelle application nommée LeStaff : une plate-forme collaborative pour médecins.

Cette start-up disposait déjà d’un backoffice (une application Symfony2) destiné à administrer et stocker ses multiples contenus pédagogiques (cas cliniques, imageries, fiches de synthèse...).

À cette époque, les données renseignées dans ce back-office servaient à alimenter les pages d’une autre application, déjà en production : prepECN.com

Nous étions donc invités à faire de même : consommer l’API de ce backoffice dans notre développement.

L’audit du back-office

En inspectant le code du back-office, nous avons relevé assez rapidement plusieurs points bloquants :

• Absence de documentation de l’application et de son API
• Peu de conventions respectées dans le code
• Mais surtout … très peu de tests

En d’autres termes :

• Il était très risqué d’utiliser une API dont le comportement était obscur
• Il nous était impossible de mettre à jour le code sans introduire de régression et/ou sans nuire à la stabilité des applications clients
• Ajouter de nouveaux tests et refactorer le code aurait été bien trop coûteux en temps.

Créer une belle API

Nous avons opté pour la création d’une API HTTP “satellite” (REST bien sûr !) qui viendrait consommer en lecture seule la base de donnée du système d’administration de contenus.

Les avantages seraient multiples :

• non-intrusif
• un contenu “sain” pour les futures applications clientes
• testable
• évolutif

Nous avons également développé un SDK (un petit client PHP) pour faciliter l’accès aux différents endpoints.

L’idée en image :

En construisant cette API au fil du développement de LeStaff, il nous a non seulement été possible d’imposer nos standards de qualité, mais aussi de nous abstraire radicalement de l’applicatif originel.

Ces quelques avantages se sont révélés en cours de route :

• Garantir un “langage omniprésent” (ubiquitous language) : renommer les données si nécessaire pour s’assurer de faire usage des bons termes métier, et ce, du mapping de la base de données jusqu’à la réponse JSON !
• Pouvoir transformer les données serialisées en sortie (par l’intermédiaire de handlers JMS Serializer)
• Décliner des réponses différentes en fonction de l’application cliente
• Ajuster finement la durée d’expiration de nos réponses
• Imposer des contraintes de formatage des données par validation JSON
• Tester de bout en bout avec Behat + PHPSpec (oui, forcément !)

La suite

Ipocrate nous a ensuite confié la refonte de PrepECN, la version étudiante de LeStaff. À ce jour, les deux applications sont en ligne : PrepECN depuis septembre 2015 et LeStaff depuis janvier 2016.

Par la suite, Ipocrate a recruté un nouveau développeur en vue d'assurer la maintenance et l'évolution de ses applications. Nous l'avons accueilli à Nantes pour une formation Symfony de trois jours ainsi que deux jours de passation.

Nous avons également assuré plusieurs mois de code review pour garantir la bonne évolution des travaux :)

Ce fut un beau challenge, avec en tout cinq développeurs chez KNP pour le backend accompagnés de plusieurs prestataires pour l'UX et l'inté.