Drupal 8 : Concevoir votre application pour Drupal 8

Cet article est extrait de notre formation drupal 8 "de Drupal 7 à Drupal 8" à destination des développeurs. N'hésitez pas à nous contacter pour en savoir plus !

Combien parmi vous se revendiquent “développeur Drupal” plutôt que “développeur PHP” ? Cela est probablement dû au fait que Drupal fonctionne grâce à un certain nombre de couches d’abstractions qui lui sont propres et que si demain vous étiez privé(e) de Drupal vous vous sentiriez démuni(e) sans Form API, Entity API, Views ou Batch API.

En pointant cela du doigt on se rend compte de la richesse d’un outil mais on peut aussi se demander si cela n’est pas une erreur. En utilisant un composant drupalo-drupalien, vous ne pourrez pas vous en resservir en changeant de technologie et c’est bien dommage. C’est une des raisons pour lesquelles Drupal 8 s’est ouvert sur le monde extérieur. Pouvoir bénéficier de composants connus et réutilisables. On parle ici de Twig, de HTTPKernel et HTTPFoundation, de l’autoloader PSR, de Guzzle, etc. D’ailleurs tout n’est pas à jeter dans Drupal, si Views devenait un composant proprement découplé il pourrait être réutilisé dans d’autres applications. Les développeurs de Commerce 2.x sont dans cet état d’esprit de design par composants indépendants et réutilisables et il est probable que cela soit une tendance de fond sur les années à venir.

L’idée derrière cela est qu’il faut garder à l’esprit qu’à chaque fois que nous concevons un nouveau projet web avec une valeur ajoutée métier, nous devons réfléchir à son architecture. Trop souvent cela se résume à choisir les modules contribués sur lesquels nous reposer, combien de view modes à créer par type de contenu ou s’il faudra utiliser Panels VS des templates VS Display Suite (troll en approche).

Une application web est composée d’objets et il y a des liens entre ces objets. Si vous utilisiez un framework il faudrait pondre un diagramme de classes et un schéma de base de données, designer vos interfaces pour rendre votre code élégant. Drupal 7 a apporté les trop peu utilisés types d’entités, profitez de Drupal 8 pour vous poser la question du bon stockage de vos données (bundle de nœud VS nouveau type d’entité VS simple table).

IC378684.png

Trop souvent le code est fragmenté et manque de recul. Pour savoir si votre application est de qualité, il suffit de vous demander cela : “suis-je capable de faire du refactoring ou de modifier des pans capitaux de l’application tout en restant serein(e) ?”. Dans la plupart des cas la réponse sera non. La faible couverture de tests (unitaires ou fonctionnels) en est l’une des principales explications. Pour cette raison, plus vous suivrez un modèle clairement défini en amont et partagé par l’équipe plus vous serez en maîtrise de votre application et, qui sait, si votre processus de production est très avancé vous réussirez à produire des tests !

Concevoir une application c’est se demander quel est le bon outil pour un usage donné. Lorsque vous designer l’infrastructure nécessaire pour faire tourner votre application vous piochez parmi des outils tels que Varnish, Nginx, Memcache, Redis, Solr.. faites la même chose sur la partie PHP. Il sera parfois plus simple d’utiliser une autre technologie voire un autre langage ou s’appuyer sur une librairie externe plutôt qu’un module Drupal pour adresser certaines problématiques. L’important est de pouvoir faire communiquer tout ce petit monde ensemble et la bonne nouvelle c’est que les webservices se sont démocratisés (encore faut-il bien les designer), facilitant par la même occasion l’échange de données. Et si vous en venez à écrire vos propres solutions, pensez à les partager, c’est la clé de l’Open Source.

Votre commentaire

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.
Votre adresse servira à afficher un Gravatar et à vous notifier des réponses. Votre commentaire sera anonymisé si ce billet est dépublié pendant plus de 3 mois.

À propos de Julien

Gérant - Co-fondateur - Scrum master & Expert technique

Utilisateur de Drupal depuis 2008, j’ai fait mes armes comme développeur chez Commerce Guys puis me suis mis à encadrer les nouveaux arrivants avant de donner des formations, participer aux avant ventes et accompagner les équipes au passage à Scrum.

Je suis impliqué dans la communauté française de Drupal depuis 2009, j’ai été tour à tour président puis vice-président de l’association Drupal France et francophonie entre 2011 et 2013.

Nous rejoindre ?

Vous avez envie de rejoindre une équipe éthique ?
Vous avez envie de faire un partenariat ?