Bonjour à tous,

Je vous propose un petit tuto, on aime bien les petits tutos mais avant de commencer je vais le remettre dans son contexte initial.

Dans un précédent article posté sur le site lesveilleursdenuit.fr, je parlais de faire un projet perso pour sortir la tête de l’eau ? Eh bien oui, j’en ai lancé un et m’y suis cassé les dents (dans le sens positif du terme).

Outre la montée en compétence significative que cela m’a offert, je me suis surtout rendu compte d’une chose: il est définitivement essentiel de définir et redéfinir son besoin exact pour pouvoir choisir l’environnement technique. Etre capable de mettre au propre votre concept et le CDC fonctionnel de votre application est déjà un travail assez long et rigoureux. La partie technique elle…demande autre chose : être clairvoyant et prévoyant, voir sur le long terme.

C’est-à-dire Pophip ? C’est à dire que les technos nous réservent souvent des surprises. Elles ont des limites, des spécificités plus ou moins adaptées à vos problématiques. En tant que dev l’envie nous vient souvent d’utiliser une techno par curiosité, par interêt ou parce qu’on nous l’a fortement conseillée. Nous devrions choisir une technologie parce qu’elle correspond à ce dont on a besoin considérant également le contexte et la maintenabilité.

C’est comme ça que je me suis retrouvé avec un environnement technique applicatif trop puissant limite usine à gaz, et un ORM à l’état embryonnaire. Joli combo qui m’a valu quelques mois de : “j’en ai marre de c’te projet”.

De manière plus explicite : j’ai lancé un projet avec Nuxt.js en front et du Sails.js en back. Le tout relié à une base MongoDB et hébergé pour 7 balles le mois sous Heroku.

Nuxt c’est cool. C’est un framework SSR (Server Side Rendering) construit sur VueJS, rapide, pratique, efficace. Je ferai sûrement un article rien que pour ses beaux yeux. Je ne peux que vous conseillez d’au moins y jeter un oeil.

Sails c’est… c’est pas si mal. Si vous ne connaissez pas je vous invite à également voir leur site web.

C’est un framework NodeJS MVC (modèle vue contrôleur) inspiré de Rails (en ruby tout ça…) et qui a adopté le principe de “convention plutôt que configuration” (le fameux convention over configuration). Il permet de créer assez rapidement des APIs REST, des Single Page Applications et des applications en temps réel. Globalement il aide le développeur à écrire moins de code, et je reconnais qu’il est plutôt pratique.

Mais alors, quel est le problème ?

Le problème est que Sails a une documentation lacunaire, une communauté assez restreinte et un ORM suffisament à l’état d’embryon pour ne pas prendre en charge le deep populate. En se baladant sur le web on nous conseille de changer d’ORM, d’importer 36 libs bref on nous conseille de changer de techno.

À cela se rajoute la question de la pertinence de l’introduction de la philosophie Ruby sur du Javascript. Ce ne sont pas les mêmes modes de pensée.

De plus, je ne trouve pas normal qu’un framework back ait 3 failles critiques de sécurité (du genre injection de code en plus) à l’audit de npm sans chercher à les corriger.

Pour finir j’ai trouvé ironique que IBM développant LoopBack (donc concurrent à Sails) ait écrit une meilleur documentation sur Sails que… Sails.

On passe donc plus de temps à chercher de la documentation qu’à l’appliquer, c’est dommage pour un framework au final très bien construit. Pour aller un peu plus loin, je vous redirige vers un article traitant des soucis de sails plus en profondeur. Certes il date de 2015, mais il faut (vraiment) croire que les problématiques du framework restent globalement les mêmes (#balancetonframework).

L’autre problème vient de moi. J’étais curieux de découvrir un Ruby on Rails version JavaScript, je voulais absolument avoir un back pour au final une application qui ne faisait qu’un CRUD assez simple sans intégration particulière de systèmes externes. J’ai ainsi mal étudié mon besoin technique, je me suis mal renseigné sur mon cheval de bataille tout ça pour l’attrait que la technologie avait et le fait qu’il y a quelques temps c’était on the wave. Pophip, la tête de turque qui veut toujours faire du Rock’n Roll hein… On ne m’y reprendra plus.

Revenons à nos moutons

Quoi qu’il en soit, je me suis petit à petit retrouvé freiné à cause de l’ORM Waterline et frustré d’avoir l’impression de passer beaucoup de temps sur Sails pour pas grand chose en plus d’avoir un back à sécuriser.

Tout ça pour dire que suivant ton expérience dans le monde du dev tu apprends petit à petit à non seulement élaborer un concept fonctionnel selon un besoin mais également à choisir correctement un environnement technique. J’entends par “correctement” le terme adapté. C’est à mon sens particulièrement important pour mener à bien un projet avec en tête la pérénisation du produit.

Cela m’amène au sujet du tutoriel qui va suivre. Il n’est plus nécessaire de rappeler l’importance du Search Engine Optimisation (SEO) visant à optimiser la visibilité d’une page web dans les résultats de recherches. De son côté le SSR permet une meilleure indexation SEO. Et ô joie nous disposons grâce aux Chopin brothers de Nuxt.js fait pour ça et restant un framework intuitif et agréable malgré la complexité plus poussée d’un développement en SSR.

Mais qui dit SSR dit il est où le serveur ? Je prends quoi comme back ? Sails ? Nest ? Juste un Express ? Et si… et si il y avait plus simple ? Je fais un CRUD relativement standard donc je pourrais penser serverless. En plus j’aimerais centraliser les web services.

Là, Firebase entre en jeu.

” Firebase est une plate-forme de développement d’applications mobiles et Web qui fournit aux développeurs une pléthore d’outils et de services pour les aider à développer des applications de haute qualité, à élargir leur base d’utilisateurs et à générer davantage de profits. Source – M.Chenot – 2018 “

Je vous propose de cliquer sur les deux liens ci-dessus si vous souhaitez en savoir plus sur Firebase.

Reprenons.

Techniquement il est possible de ne faire que du Vue au lieu de Nuxt mais on a dit que l’on veut du SSR. Donc non seulement je peux utiliser Firebase Hosting pour l’hébergement, Firebase Auth pour la gestion des utilisateurs et Firestore pour la base de données mais je peux également profiter des Cloud Functions for Firebase pour ce qui est du SSR.

On fait les comptes :

Suppression du backend
Centraliser la plupart des web services en un seul ainsi que la BDD
Déploiement au CLI en une ligne de commande
Cloud function pour le SSR
Scale automatique
Serverless
Meilleure indexation (SEO)
Les qualités de Nuxt en matière d’application (SPA, PWA etc…)
Hébergement gratuit
Cela me semble vraiment pas trop mal cette fois comme choix. Maintenant la question c’est: comment va-t-on s’y prendre pour mettre tout cela en place ?

Je vous donne donc maintenant rendez-vous dans la partie 2 pour voir comment on va pouvoir déployer une application SSR Nuxt sous Firebase.

On est d’accord c’est une grosse introduction, mais cela me tient à coeur de montrer un chemin de pensée qui mènerait à revoir son environnement technologique voir son infrastructure.

Bien à vous,