Vers quelle Technologie aller pour réussir votre projet web (3ème partie)

Comme je vous l’indiquais dans mon précédent article, dans le cadre d’une requête venant d’un navigateur, les Frameworks peuvent être utilisés pour deux scénarios :

  • Soit le Framework fait le traitement de la requête et renvoie une page HTML complète, le rendu est donc fait côté serveur et le navigateur ne fait qu’afficher la page.
  • Soit le Framework lit la requête dans le navigateur, fait une requête à une ou plusieurs urls ( API REST ) si besoin pour récupérer des données. Les données sont affichées directement dans le navigateur en modifiant le HTML, c’est le rendu côté client.

Les plus beaux stands du Bazar *: Le rendu fait côté client

Cette technique est utilisée depuis très longtemps mais elle n’a jamais été aussi structurée que depuis quelques temps. Le séquençage de la requête est le même que le rendu fait côté serveur, à la seule différence que le corps de la page est vide. En effet, c’est lors de l’initialisation du javascript que la page va se construire et que le contenu va apparaître. Ce temps d’initialisation, peut s’étendre d’une fraction de secondes à plusieurs secondes en fonction de l’ordinateur, de l’utilisateur et de la complexité de l’application.
Ainsi les données brutes ne sont pas traitées par ces Frameworks (c’est possible mais je ne vous le conseille pas), ils ne s’occupent que de l’affichage.
On peut éviter cela avec des solutions qui génèrent le contenu de la page d’arrivée de l’utilisateur, le reste de la navigation se faisant directement côté utilisateur (avec Ember Fast ou ReactJS). Grâce à cette approche on résout le problème de la page blanche pour l’utilisateur et les robots des moteurs. L’internaute voit ainsi une page avec du contenu et les robots peuvent indexer ces contenus.
Le langage Javascript, a un nombre incroyable de Frameworks. Grâce à l’avènement de NodeJS et la démocratisation de NPM, le langage Javascript devient LE langage du navigateur ( aka “côté client” ). Personnellement je pense que ce bazar est une bonne chose, mais il faut avouer que c’est difficile de s’y retrouver lorsqu’on veut choisir.
j’ai donc pris le parti d’analyser seulement EmberJS, AngularJS et ReactJS avec Flux.

  • EmberJS appartient à Tilde, entreprise qui fournit des solutions Rails.
  • AngularJS a été créé par un développeur pendant son temps libre au sein de Google. Mais aujourd’hui, google a assigné une équipe dédiée pour son développement. La version 2 d’Angular est même très soutenue par Microsoft.
  • ReactJS et Flux sont issus de Facebook et sont le résultat de plusieurs années d’optimisation de facebook.com.

 

Remarque :
Google crawle les sites web construits en Javascript et il existe quelques maigres recommandations officielles de leur part sur le sujet. Au moment ou j’écris ces lignes et à ma connaissance, il est le seul moteur de recherche qui est capable de le faire. Il faut donc pré-générer les pages en HTML pour les autres moteur de recherche.
Vous avez le choix entre deux approches : soit vous pouvez le faire à la volée lorsqu’un robot se présente, soit vous générez toutes les pages de votre site à l’avance.
Quelque soit le choix que vous aurez fait, vous pouvez passer par un tiers ou mettre en place une solution vous même. La mise en place de la solution prend du temps mais requiert aussi :

  • l’intégration de la solution dans votre processus de mise en production.
  • la mise en place d’un moyen de test des pages générées pour les chefs de projet mais aussi les développeurs.

En définitive, tout est une question de ressource, si vous en avez les capacités, cette technologie peut vraiment vous aider.
Personnellement, je pense que si le projet a une forte dépendance au référencement naturel, une technologie faisant le rendu côté serveur est plus adaptée. Aussi bien pour des raisons humaines que budgétaires 🙂
Les cas de Ember Fastboot et de ReactJS : Le premier est un serveur fait par l’équipe du Framework EmberJS pour générer la page côté serveur à la volée. Ainsi l’’internaute voit quelque chose dans son navigateur le temps que le navigateur finisse de charger le javascript contenant l’application. Il a été créé pour le Framework EmberJS mais la documentation indique qu’il peut être utilisé avec ExpressJS. ReactJS s’intègre aussi très bien avec ExpressJS pour permettre de générer des pages à la volée. Vous pouvez évidemment mettre en Cache les pages générées par les deux solutions pour économiser du temps de traitement.

Communauté

AngularJS a la plus grosse communauté entre EmberJS et ReactJS. C’est le plus vieux des trois et l’aura de Google a influencé grandement sa popularité.
Le Couple ReactJS+Flux à une communauté qui augmente également très rapidement. EmberJS à une communauté plus large que ReactJS mais elle est relativement stable depuis quelque années. Trouver une réponse lors de la phase de démarrage ne devrait pas être un problème pour les trois Frameworks.
Remarque pour les développeurs :
Je parle de couple ReactJS+Flux car ReactJS seul n’est pas un Framework à proprement parler. En effet, il ne s’occupe que des composants qui permettent l’affichage du contenu. Flux, s’occupe de rapatrier la donnée. Par ailleurs, il faut bien comprendre que Flux est avant tout un concept , même si Facebook a mis à disposition son implémentation, il en existe de nombreuses autres.

Documentation

Les documentations des trois Frameworks sont excellentes. Flux étant un concept, sa documentation dépend du projet qui en a fait l’implémentation. Certaines comme Fluxxor sont plutôt bien faites, à contrario, la libraire mise à disposition par Facebook a une documentation plutôt limité.
Les communautés de ces 3 Frameworks font un gros travail d’approfondissement dans la compréhension des concepts que ces Frameworks implémentent. Ils publient énormément de tutoriels écrits et de formations vidéos très abordables.

Infrastructure

Ces Frameworks côté client n’ont pas besoin d’une infrastructure très complexe : Il leur faut simplement un serveur HTTP envoyant la page initiale (avec ou sans contenu pré-généré).
En effet, le gros de l’infrastructure sera pris par l’API REST côté serveur, qui va communiquer avec le Framework. Ce dernier peut être également écrit en Javascript (ExpressJS par exemple) ou grâce à une application en PHP.
Une chose est à retenir : un Framework front end va communiquer avec un autre applicatif pour traiter la donnée, il le fait généralement en REST. C’est l’application côté serveur qui va effectuer les requêtes en base de donnée et envoyer les données au Framework.

Concept à maîtriser

Les Frameworks front end requièrent la compréhension des patrons de conceptions ( Design Pattern ). Angular 1 et Ember ont tous les deux implémentés le patron de conception MVC : Model, Vue, Controlleur.
Mais Angular 2 et ReactJS on une approche différente : ils définissent les différentes parties comme des composants ( AngularJS, ReactJS ). Ce concept n’est pas nouveau en soi mais son implémentation dans le cadre de ces Frameworks a besoin d’être compris et maîtrisé.
L’optimisation côté client est un point à ne pas oublier. L’application étant exécutée entièrement côté client, le chef de projet devra avoir une vision claire des utilisateurs ciblés.
Cette information va aider le développeur à optimiser les performances de l’application.
Si par exemple les utilisateurs sont dans des zones ou la connexion internet est mauvaise et/ou qu’ils possèdent des ordinateurs peu puissant, il faudra rendre l’application la plus légère possible tout en gardant les fonctionnalités.
Un des enjeux par exemple pour une application étant utilisée dans des zones de connexion limitées, est d’être la plus légère possible tout en conservant les fonctionnalités essentielles.
Il faut absolument savoir compiler : avec la ribambelle de packages utilisés dans nos projets, il faut savoir mettre en place un moyen de compiler l’ensemble du code dans un seul fichier ( Webpack ou Browserify ). Ce fichier est alors envoyé côté client et est exécuté.
Évidemment, Il faut aussi mettre en place des tests utiles pour éviter les régressions lors du développement.

Avantage

Ces Frameworks permettent de créer des applications rapidement. Ils ont tous un système de modules. Cela permet d’avoir une séparation claire des fonctionnalités dans le code. Cela permet aussi de récupérer des modules réalisés par d’autres personnes afin de gagner du temps sur le développement. Elles permettent de mettre en place des sites très modulables et personnalisables. En effet, l’essence même de ces outils est de manipuler les éléments HTML d’une page. De ce fait, avoir des fonctionnalités qui personnalisent l’affichage est possible.

Chef de projet

Ces Frameworks permettent de mettre en place des applications qui ne rechargent plus la page entière, seule la section qui a besoin de données est rechargée.

Développeur

Leurs composants de base permettent de gérer l’affichage mais aussi de se brancher à des APIs facilement. Ils permettent aussi de réduire la charge du serveur car ce dernier n’aura plus qu’à traiter la donnée et à la renvoyer dans un format très simple ( JSON ).Il n’aura donc plus besoin de générer la page de l’utilisateur en HTML.

Inconvénient

Au même titre que les Frameworks cités dans la partie précédente, les Frameworks front end demandent un temps d’adaptation. Même s’ils sont plus légers, le temps est relatif à l’expérience du développeur. De plus, ce dernier doit faire preuve de discernement lors de la recherche d’informations pour ne pas tomber dans des pièges.

Développeur

La mise en place des compilateur est assez long. En effet, la configuration peut être assez longue car ils ont tous leur façon de gérer les différentes étapes. Si votre application est un Saas, il faut prendre des précautions à la taille des fichiers JS envoyés au client. En effet, il faut bien configurer le compilateur pour qu’il crée plusieurs fichiers de sortie correspondant au contexte de l’utilisateur.

Vers quelle Technologie aller pour réussir votre projet web (2ème partie)

Lorsque le navigateur demande un site web au serveur, il fait une requête. Lors de l’utilisation d’un Framework, la réponse à cette requête est généralement traitée de deux manières :

  • Soit le Framework fait le traitement de la requête et renvoie une page HTML complète, le rendu est donc fait côté serveur et le navigateur ne fait qu’afficher la page.
  • Soit le Framework lit la requête dans le navigateur, fait une requête à une ou plusieurs urls ( API REST )  si besoin pour récupérer des données. Les données sont affichées directement dans le navigateur en modifiant le HTML, c’est le rendu côté client.

Dans cette seconde partie, nous allons aborder le rendu côté serveur pour les Frameworks PHP et Javascript.
Le langage PHP a énormément de Frameworks mais je ne parlerai que de Symfony 2/3 et Zend 2. Il sont pour moi les deux solutions les plus pérennes et les plus viables. En effet, elles sont soutenues et maintenues par des entreprises en coopération avec la communauté.
Pour Javascript, j’ai choisi ExpressJS avec un moteur de template; vous pouvez choisir celui que vous voulez car il font tous le même job : faire le rendu de la page en HTML dans le serveur. Fait par un seul homme à ses débuts, il est aujourd’hui maintenu par une grosse communauté et cet effort est soutenu par StrongLoop qui est une entreprise appartenant à IBM.

La Cathédrale* : le rendu fait côté serveur

C’est la technique “historique” de génération de page web, en voici la séquence simplifiée :

  1. Le navigateur envoie une requête au serveur.
  2. Le serveur renvoie du html avec les fichiers de styles et le javascript.
  3. Le navigateur affiche le html, utilise le css contenu dans les fichiers de style pour disposer et styliser les différents tags html.
  4. Le javascript s’exécute et met en place les interactions de l’interface du site ( popin lors du clic sur un mot ou un bouton, lecteur média, …etc ) et si besoin récupère des données supplémentaires à afficher.

Remarque :
Les CMS présentés dans la précédente partie utilisent en général cette technique pour afficher les sites web. Mais il existe des plugins qui permettent de faire des rendus côté client, nous détaillerons cette technique dans la prochaine partie.
jesus love frameworks

Communauté

Zend Framework et Symfony ont des communautés très larges. Zend Framework est considéré comme le framework historique de PHP mais il connaît un déclin fasse à Symfony depuis quelque années.
Les communautés de Zend Framwork et de Symfony sont respectivement animés par Zend Technologie et SensioLabs . Ces entreprises soutiennent l’effort de développement fait par la communauté mais sont très largement les moteurs des différentes sorties de versions. Beaucoup d’entreprises proposent aujourd’hui des prestations dans ces deux technologies mais Symfony 2 est le plus choisi ces dernières années.
ExpressJS est l’un des premiers framework NodeJS. ExpressJS est un peu l’équivalent de Zend pour NodeJS. De nombreux tutoriels existent, il est donc simple de trouver une réponse en cas de blocage.

Documentation

Zend Framework a eu une documentation passable à la sortie de la version 2. Mais ils se sont améliorés au fil des sorties des versions mineurs (2.x). La version 3, qui est sortie récemment, à mis en place une excellente documentation pour ses packages de base. Des tutoriels sont mis en ligne depuis peu concernant l’utilisation des différents modules à l’image de Symfony.
Symfony 2 a quant à lui une très bonne documentation. La documentation de référence est complétée par le CookBook qui permet d’avoir des cas pratiques d’utilisations des différentes parties du framework appelé bundles. Cela facilite grandement la compréhension des différents bundles de base et permet ainsi de réduire le temps d’apprentissage du framework.
ExpressJS étant très simple, sa documentation est moins lourde à parcourir que les deux gros frameworks PHP. Il n’y a que la documentation de référence sur le site officiel mais trouver un tutoriel sur un cas d’utilisation est très simple.

Infrastructure

Les frameworks PHP nécessitent une une infrastructure classique LAMP ou LeMP ( Linux, Apache/eNginX, Mysql/MariaDB, PHP ), mais requiert une configuration du serveur HTTP (Apache ou eNginX) plus poussée. Il s’installe difficilement chez les hébergeurs mutualisés, mais ce n’est pas non plus  impossible. Je vous conseille vivement d’utiliser eNginX couplé à PHP-FPM ou à HHVM pour augmenter le temps de traitement PHP.
ExpressJS fonctionne avec le serveur HTTP intégré à NodeJS. Sur les grosses applications NodeJS, on peut voir un serveur eNginX en face du serveur NodeJS. c’est à dire que la requête du navigateur va d’abord passer par eNginX avant d’aller sur un serveur NodeJS. Cela permet d’avoir eNginX qui partage la charge entre plusieurs serveurs NodeJS dans la même machine.
Je vous conseille également de mettre en place un/des serveur(s) de Cache afin d’accélérer la navigation de l’utilisateur.

Concepts à maîtriser

Les frameworks PHP et Javascript requièrent  la compréhension des patrons de conceptions (Design Pattern ). Le patron de conception ( c’est vraiment moche la traduction 😀 ) le plus important à maîtriser est le MVC : Modele, Vue, Controller.
Symfony 2 et 3, Zend 1 et 2 et ExpressJS 4 utilisent d’autres Design Pattern comme le Singleton, la Factory, l’Observer, la Façade… etc. Il faut bien comprendre leur fonctionnement global pour bien les utiliser. C’est le seul moyen d’architecturer correctement les différentes fonctionnalités en utilisant toute la puissance offerte par ces frameworks.
Il faut savoir correctement organiser les données dans la base de donnée. Avec une base de donnée relationnelle, l’organisation des données entre les tables est cruciale dans la performance de le traitement des requêtes. Les bases de données NoSQL sont plus permissives dans leur organisation et demandent donc une plus grande rigueur dans l’organisation des schémas.
Enfin, il faut savoir mettre en place des tests utiles afin d’éviter des régressions lors du développement. En plus de tous cela, je vous conseille de mettre en place un déploiement continu de l’application.

Avantages

Ces frameworks permettent d’accélérer le développement. Ils ont tous un système de modules. Cela permet d’avoir une séparation claire des fonctionnalités dans le code. Cela permet aussi de récupérer des modules réaliser par d’autre personne afin de gagner du temps sur le développement. Ils incorporent des modules de base qui leur donnent une grande flexibilité et leur permet d’être le socle d’une large variété d’applications.

Chef de projet

Grande liberté dans les fonctionnalités. Une gestion du SEO peut s’adapter aisément. Les templates étant fabriqués par les développeur, les designs peuvent être personnalisés pour les fonctionnalités. Accélère le développement des fonctionnalités.

Développeur

Les Frameworks cités plus haut ont des outils pour vous guider dans l’implémentation des fonctionnalités. Ils permettent de limiter les problèmes techniques et incite aux bonnes pratiques d’écriture du code. Enfin, Beaucoup de cas pratiques différents sont disponibles sur le web pour vous aider.

Inconvénients

Étant un ensemble complexe, un framework demande un temps d’adaptation. Ce temps est relatif à l’expérience du développeur. Ce dernier doit donc faire preuve de discernement lors de la recherche d’informations pour ne pas tomber dans des pièges.

Vers quelle Technologie aller pour réussir votre projet web (1ère partie)

Dans le merveilleux monde du web, lors du démarrage d’un projet, le choix des technologies est crucial. Lors d’une refonte totale, le choix est moins difficile… mais ne veut pas dire simple 🙂
Dans le cadre d’une refonte, on peut s’appuyer sur l’expérience acquise auparavant pour repenser l’application. On peut aussi mettre en place une nouvelle expérience plus saine pour le développeur (Developper eXperience) afin de fluidifier la réécriture des fonctionnalités existantes et d’améliorer la production de nouvelles fonctionnalités.
En effet, le fait d’avoir des fonctionnalités déjà en place en environnement de production permet une analyse simplifiée du code et de l’UX.
De plus, contrairement à un nouveau projet, le besoins est clair dans une solution déjà en place. D’autant que le projet a parfois connu de nombreuses modifications de la part des demandeurs.
Si lors d’une refonte le besoin n’est pas clair pour les développeurs et le Chef de projet, c’est qu’il y a un autre problème 😉
Il faut donc correctement comprendre le besoin pour faire les bons choix. Dans le cadre d’un nouveau projet, le besoin n’est pas évident à cerner, aussi bien pour le demandeur (qui a souvent une idée floue de la solution), que pour le chef de projet ou PO qui va devoir s’approprier ce besoin et piloter le projet. Cette solution va être ensuite créée par un ou plusieurs développeurs.
En tant que développeur, on a le choix entre le confort d’un langage et/ou framework qu’on connaît, et l’aventure avec un nouveau langage et/ou framework.
Je suis partisan de l’adage qui pour un projet dit, , “la bonne technologie est la technologie que l’équipe connaît la mieux”. Mais parfois on est amené à faire un choix en fonction des contraintes. Ainsi, pour aider les développeurs, aventureux et moins aventureux, mais aussi les Chef de projets curieux, je vous propose un petit guide pour orienter votre recherche. Ce guide n’a pas vocation à vous donner une réponse toute faite mais à vous donner des pistes de réflexion autour des différents outils (tout cela n’est évidemment mon humble avis).
Nous allons donc commencer par les trois CMS PHP les plus en vue : WordPress, Drupal, Joomla. Dans les parties qui vont suivre, nous aborderons les frameworks. Ainsi, nous verrons leur utilisation dans le cadre d’un rendu fait côté serveur puis nous terminerons par le rendu fait côté client.
Cette comparaison prendra en compte les points suivants :

  • Communauté : Plus le nombre d’utilisateurs est important, plus les solutions aux problèmes rencontrées sont nombreuses.
  • Documentation : un bonne documentation peut faire gagner beaucoup de temps.
  • Infrastructure : Beaucoup de points sont communs à PHP et JS …et pour toutes les applications web en général. Ainsi le système d’exploitation des ordinateurs servant a héberger l’application sont généralement tous sous Linux. L’application web a besoin d’un serveur HTTP pour envoyer et recevoir des requêtes, en général Apache, ou eNginX. Pour sauvegarder les données, il lui faut une base de donnée, là encore, en général on retrouve des systèmes base de données relationnelles comme MySQL, mais l’utilisation de bases de donnée NoSQL augmente d’année en année. Le point de divergence vient des moyens nécessaires au traitement de la requête : avec PHP on passera par un binaire, avec Javascript, on utilisera NodeJS.
  • Concepts : Certain outils demandent la maîtrise de concepts assez avancés par les développeurs.
  • Avantages et Inconvénients d’un point de vue développeur et Chef de projet.

Les kits prêts à l’emploi : les CMS

Un CMS est une solution clé en mains pour créer un site, nécessitant simplement du contenu dynamique structuré. Autrement dit, c’est une pâte à gâteau prête à être mise au four 😉
Quand on compare les parts de marché des CMS dans le trafic web, on s’aperçoit vite qu’un CMS dépasse tous les autres : WordPress. La part exacte de WordPress n’est pas vraiment déterminée mais il se situe entre un tiers et deux tiers ( 1 , 2 , 3 ). WordPress est un CMS très ( trop ? ) généraliste au même titre que les deux autres CMS qui le suivent ( difficilement ) Joomla et Drupal.

Communauté

WordPress dispose d’une très large communauté car orienté très grand public contrairement au deux autres. Drupal et Joomla ont des communautés moins larges mais ont un public beaucoup plus technique car leur prise en main est plus compliquée.

Documentation

Très bonne documentation. Les concepts avancés sont bien expliqués mais parfois un peu abstrait. Néanmoins, vous pouvez aisément trouver des articles sur des utilisations avancées appliqués à des cas plus réels.

Infrastructure

Une infrastructure classique LAMP ou LeMP ( Linux, Apache/eNginX, Mysql/MariaDB, PHP ) suffit amplement pour faire fonctionner ces CMS. Beaucoup d’hébergeurs comme OVH ou 1&1 proposent des offres sur des serveurs mutualisés. Ces derniers ont l’avantage d’être pré-configurés, ce qui permet un déploiement rapidet. Mais si vous décidez de passer par un serveur dédié, les configurations nécessaires ne sont pas très difficiles. Sur des sites à fort trafic, il est vivement conseillé de mettre en place des serveurs de cache pour accélérer la navigation de l’utilisateur.

Concepts à maîtriser

WordPress ne requiert pas de concepts avancés à maîtriser et la prise en main est très rapide. Drupal et Joomla, dans leur dernière version, ont des organisations plus complexes que WordPress. Mais leur utilisation au jour le jour est plutôt simple après une petite période d’adaptation.

Avantage

La solution de prendre un CMS est idéale lorsque le besoin est simple ( vous avez un exemple devant vos yeux 🙂 ).

Chef de projet

Le SEO est facile à mettre en place grâce aux plugins. Il y a énormément de templates disponibles.

Développeur

Peut de choses à maîtriser. Facile de faire une template soi-même. Facile de faire un plugin soi-même.

Inconvénient

Étant très répandus, les CMS sont très exposés aux attaques : lorsqu’une faille est trouvée sur un site ayant l’un des CMS , il peut être exploité sur tous les autres sites ayant le même CMS. Les performances du site peuvent aussi s’effondrer si un plugin et/ou un serveur pour faire du Cache n’est pas installé.

Chef de projet

Il faut mettre en place un certain nombre de plugins pour pouvoir bénéficier d’un SEO efficace. La gestion du contenu personnalisé peut vite devenir contraignant si le plugin n’est pas assez bien adapté.
Implémenter des fonctionnalités non prévues par le CMS peut être long. Les templates téléchargeables ne seront pas rapidement adaptables (voir pas du tout parfois) pour certains besoins particuliers. En effet, les CMS on chacun leur façon de surcharger les modules fournis dans les templates.

Développeur

Difficiles à maintenir lorsqu’ils sont utilisés pour autre chose que du contenu simple (Application SAAS ou Ecommerce ). Les templates téléchargeables deviennent parfois… non en fait très souvent :), un cauchemar à modifier et maintenir. Et parfois, avec le même CMS, vous aurez des manières très différentes de surcharger les templates. En effet, même s’il existe des bonnes pratiques, il ne s’applique qu’à des templates simples; les templates plus complexes s’organisent de manière très différente en fonction des personnes qui les réalisent.
Les plugins peuvent être longs et contraignants à créer ou à adapter.
Les cas pratiques disponibles sur le web ne sont pas très diversifiés et obligent à utiliser des plugins peu ou pas maintenus.