Psono.com est maintenant propulsé par Gatsby

Dans le passé, Psono.com était alimenté par Odoo v11. Odoo est un excellent CMS, mais comme nous avons dû l'apprendre, les mises à jour sont difficiles. Leur module de site web a notamment causé de nombreux problèmes lors de nos tests. Odoo v11 atteindra sa fin de vie fin 2020, nous avons donc été obligés de trouver une solution.

Nous avons réfléchi à différentes options : mettre à jour vers Odoo v13 et migrer manuellement tout le contenu et les personnalisations nous-mêmes, engager quelqu'un pour faire la migration pour nous, ou migrer complètement vers un nouveau CMS. Nous avons décidé de migrer complètement Psono.com et continuerons à utiliser v11 derrière un pare-feu pour le migrer ultérieurement (nous n'avons pas encore décidé quand).

Les raisons derrière cette décision étaient :

• Nous n'avons que très peu de contenu à migrer pour Psono.com. Principalement quelques articles de blog.
• Une migration vers Odoo v13 reproduirait le même problème dans deux ans lorsque v13 atteindra sa fin de vie, potentiellement avec beaucoup plus de données à migrer.
• Nous n'étions pas très satisfaits des capacités de personnalisation des sites Web d'Odoo v11. Tout est extrêmement complexe avec leurs modèles stockés dans la base de données.
• Les coûts. Engager quelqu'un pour faire la migration nous aurait coûté au moins 5000 USD, voire plus.
• La communauté d'Odoo était très active, mais avec les évolutions récentes de leurs licences et la migration des fonctionnalités et plugins vers des solutions payantes et le passage de tout derrière un paywall, la communauté est morte.
• Psono.com est principalement un site Web statique avec du contenu statique. Si nous devions avoir du contenu dynamique, nous pourrions l'intégrer via des API.

Le parcours

Après avoir pris la décision de migrer, nous avons dû choisir quel framework utiliser. Il y a des frameworks classiques comme Hugo que nous avons utilisés, mais leur fonctionnalité est limitée. En cherchant des alternatives, nous avons trouvé quelques solutions dans le monde de Node/React.

Je voulais écrire ici "solutions excellentes", mais je ne pense pas que quoi que ce soit dans l'état actuel du développement frontend mérite ce titre. Vous posez peut-être la question "cassé"? Vous souvenez-vous des temps où les développeurs pouvaient créer un site web avec un index.html et une balise script pour charger jQuery et commencer à développer des sites web? Maintenant, vous avez besoin de npm ou yarn, vous devez comprendre package.json, les scripts webpack, des frameworks modernes comme Angular ou React qui apportent tous leur propre client avec eux. JSX ou TypeScript. Des fonctionnalités comme le hot reloading ne fonctionnent pas de manière fiable (fichier non surveillé, certaines modifications nécessitent un redémarrage complet, ou le hot reloading est déclenché trop tôt, de sorte que vous devez de toute façon rafraîchir manuellement) et vous finissez par tuer des serveurs de développement et attendre des minutes pour qu'ils soient de nouveau fonctionnels (au moins dans des projets plus importants). (C'est nostalgique de simplement appuyer sur F5 et d'avoir tout sous la main sans aucun problème!). Sans mentionner un nouveau framework ou outil au moins tous les six mois où les anciens outils sont abandonnés quotidiennement. Je pourrais facilement remplir des pages en me plaignant de l'état actuel du développement frontend. Quoi qu'il en soit, revenons au sujet principal.

En l'absence d'alternatives raisonnables, les meilleures options (au moment où j'écris ceci) seraient next.js et gatsby. Du moins, c'est ce que certains articles prétendent. Les deux sont également populaires si vous comparez les étoiles ou les commits sur Github. La seule différence que nous avons pu identifier lors d'une première évaluation est la nécessité d'un composant serveur pour next.js, alors que gatsby crée des sites statiques (S'il vous plaît, ne me tuez pas maintenant si next.js peut fonctionner sans serveur actif ! :D)

Nous avons donc un peu joué avec Gatsby et cela semblait bien. Comme étape suivante, nous avons cherché un thème. Gatsby est un "nouvel" utilitaire, donc tous les thèmes que nous avons trouvés étaient encore à un stade très basique. Trente minutes et un peu d'argent plus tard, nous avions un thème visuellement attrayant qui couvrait au moins certains des composants nécessaires, et nous avons commencé à le modifier.

Comme option d'hébergement, vous pouvez choisir de nos jours entre plusieurs fournisseurs, à savoir Firebase, netlify, Cloudflare, Vercel, simple stockage cloud GCP ou AWS Cloudfront, serveurs propres, conteneurs Docker exécutés sur Kubernetes (je devais le mentionner !), ... (Vous vous souvenez de l'époque où vous louiez simplement un espace Web pour 5 $ par mois avec PHP et une base de données MySQL :D ... mais c'est pour un autre article...)

Après les avoir comparés, lu quelques critiques et examiné les combinaisons possibles (comme Cloudflare devant Firebase) nous avons initialement essayé Cloudflare. En tant que grands fans de leur service, c'était un choix naturel, mais malheureusement, leur utilitaire Wrangler avait des problèmes. Tout d'abord, il affichait toujours une erreur et nous n'avons pas pu nous authentifier... Les erreurs initiales ont disparu le lendemain (peut-être qu'un nouveau bash a aidé), mais le problème d'authentification a persisté. Je crois que j'ai dû faire une erreur et j'ai abandonné après quelques heures de lecture de leur documentation et d'essai de différentes solutions.

Netlify était un autre candidat, mais vous devez soit le connecter à un fournisseur Git et le laisser construire (nous voulions utiliser GitLab CI) soit télécharger manuellement le résultat de la construction. Peut-être qu'ils ont une option quelque part pour télécharger le résultat de la construction via une API, mais je n'en ai pas trouvée. Une alternative aurait été un dépôt où nous poussons effectivement le résultat de la construction, mais cela semblait inutilement complexe… Un autre problème pour moi est leur modèle de tarification. Ils facturent par membre (!!!) un montant assez important. Gardez à l'esprit que ceci est pour un site Web statique. Des déclarations comme "4× la bande passante" rappellent de mauvais souvenirs des temps d'hébergement "fair use" où les gens vous expulsaient si vous utilisiez trop…

Comme quatrième service, nous avons essayé Firebase (qui, en tant qu'avantage, est gratuit pour notre bande passante et nos requêtes cibles) et tout a fonctionné dès le départ. Leurs capacités de redirection sont un peu limitées, donc mapper les anciennes URL vers des plus belles est devenu un peu fastidieux, mais quelques règles de redirection plus tard, tout fonctionnait. Leur tarification semble raisonnable et vous êtes facturés pour les ressources serveur. Il faut éviter tous leurs services supplémentaires pour éviter l'enfermement propriétaire, mais nous n'avions besoin que d'hébergement.

Nous avons également brièvement vérifié vercel, mais leur exigence de se connecter avec un compte GitHub et ensuite une permission avec "Agir en mon nom" m'a découragé avant même de m'inscrire.

Le blog a été le plus difficile à migrer. Nous avons fini par copier tout le contenu manuellement. Ce n'est pas quelque chose que vous devriez faire avec un blog plus grand, mais notre blog n'avait que quinze posts. Gatsby prend en charge plusieurs mécanismes, mais nous voulions quelque chose de simple que quelqu'un sans connaissances techniques pourrait utiliser pour créer de nouveaux articles de blog. Nous avons décidé d'utiliser le markdown et avons dû apprendre à instruire gatsby pour lire les pages markdown. Le mécanisme réel nous a pris environ une demi-journée avec toute la gestion des images. Un joli thème de blog post et les images ont pris une autre demi-journée.

Après avoir migré tout le contenu et modifié lourdement le thème, nous avons automatisé notre déploiement avec Gitlab CI, donc une simple poussée déclencherait notre pipeline de build et déploierait tout sur Firebase.

Pourquoi Gitlab et pas Github ? Github est en tête pour des raisons historiques. Ils ont actuellement au moins 80% de tous les développeurs et projets. Gitlab, en revanche, fournit des fonctionnalités. C'est pourquoi dans le passé, nous avons décidé de choisir Gitlab, car il n'y avait eu aucun développement de fonctionnalités significatif sur Github pendant des années. Cela a maintenant changé de manière spectaculaire depuis que Microsoft a acheté Github et Github Actions sont une étape importante, mais Github a encore un long chemin à parcourir s'ils veulent rivaliser avec Gitlab. Donc pour nous qui hébergeons tous nos projets sur Gitlab, c'était un choix naturel de l'utiliser pour ce projet aussi.

La conclusion

Et c'est là où nous en sommes maintenant :

• Gatsby comme CMS
• Thème commercial
• Blog alimenté par Markdown
• Gitlab CI pour les déploiements automatisés
• Hébergement Firebase

Nous étions plutôt satisfaits de ce résultat et le nouveau site Web est bien mieux!