Choix de la technologie Back-End

Bonjour !

Nous avons pour ce projet, comme déjà précisé dans notre premier article, une application qui nous sert d’API ainsi qu’une application pour l’utilisateur. Nous allons vous présenter notre choix de technologie pour cette première partie, dite « Back-End ».

Introduction

Le choix du type de technologie avait déjà été fait lors de l’initialisation du projet, en fonction de nos compétences déjà acquises, de nos affinités ainsi que du contenu du Master. Nous avions décidé d’utiliser un framework PHP, si possible basé sur Symfony car ce dernier est l’outil que j’utilise en entreprise. Shijin n’avait quant-à-elle pas de préférence car n’utilisant pas d’outil back-end dans le cadre de sa mission en alternance.

Le type choisi, nous avons fait une recherche des différentes possibilités ouvertes à nous :

• API Platform : http://api-platform.com/
• Silex : http://silex.sensiolabs.org/

Pourquoi API Platform ?

Après lecture de différents documents sur Internet ainsi que les documentations disponibles pour ces deux options, nous avons décidé que nous utiliserions API Platform.

Les raisons principales de notre choix sont :

• API Platform est un framework spécialisé pour les API : Le framework est ciblé pour notre besoin, il n’y a pas besoin d’outils externes ou d’adaptations pour le transformer en API. Les Documentations officielles sont donc elles-aussi centrées sur l’API.
• API Platform mâche le travail et s’occupe de tout : L’outil est très très facilement installable et fait la majeure partie du travail à la volée (Pas de controller ou de repository à écrire mais uniquement les entities). C’est de la magie !
• API Platform est un framework créé et maintenu par Kévin Dunglas : C’est un développeur de la team Core de Symfony et aussi un intervenant dans notre Master cette année! Nous avons donc l’opportunité de rencontrer le créateur de l’outil que nous utilisons lors des cours de PHP !

Et si ce n’était pas le meilleur choix ?

Aux points négatifs imaginés lors du choix de l’outil, ce sont ajoutés les points négatifs découverts lors de son utilisation lors des premiers jours de développement. Tout comme la liste des raisons qui nous ont fait choisir API Platform, la liste des inconvénients n’est pas complète et est subjective mais cela peut tout de même vous servir à choisir pour vos projets! 😉

• API Platform est trop magique : Oui, c’est un avantage pour la majeure partie de nos entités qui ont mis que peu de temps à être écrites et ensuite rendues disponible par notre API. Cependant, dès qu’un cas exceptionnel est à implémenter, nous avons du mal à comprendre comment cela est possible. Il est bien sur possible de passer outre la magie de API Platform et de coder certains éléments nous-même. Mais cela ne marche pas de la même façon qu’un outil classique.
• API Platform n’est pas encore assez utilisé : Ça, on s’en doutait un peu plus au vu du nombre de résultats sur internet lors de nos recherches. La documentation officielle est bien écrite, cependant elle ne couvre vraiment que très peu d’exemples et il est parfois difficile pour nous de l’utiliser pour notre projet. Dans d’autres outils éprouvés, nous aurions trouvé un grand nombre de personnes ayant trouvés des solutions à des problèmes plus proches des nôtres. Stack Overflow ne nous sauve pas autant qu’il aurait pu pour d’autres outils !

Nous pouvons aussi revenir sur la raison n°3 qui est celle que le créateur de l’outil intervient dans notre master. En effet, cela reste une aide importante. Cependant, le cours arrive assez tard dans notre master et malheureusement Platine ne peut pas attendre que nous en apprenions plus sur Symfony.

Voilà pour cet article que j’espère suffisamment complet pour vous aider dans votre choix ! Bientôt la même chose pour nos choix pour les technologies de Front !