J'ai porté mon Trello Meteor 2.0 en Meteor 3.0

Il y a 3 ans, sur ce même blog (eh oui, le temps passe vite les amis), je vous avais partagé un projet où je refaisais un Trello très simpliste avec Meteor.JS 2.0.

Lien vers l'article.

Pour rappel, Meteor.js est un framework JS ou TS full-stack qui s’appuie sur Node, Express, des WebSockets DDP (Distributed Data Protocol), une base Mongo qui utilise ces WebSockets, avec une partie front appelée MiniMongo, qui synchronise les données avec le serveur pour maintenir des données "fraîches" côté client.

Le projet a connu une grosse hype entre 2012 et 2015, voire jusqu’en 2017.

Mais attention : ce n’est pas la hype qui définit l’état ou l’intérêt d’une technologie. Le framework reste pertinent, et propose toujours des choses qu’il est difficile de faire ailleurs (du moins, sans avoir besoin d’installer quoi que ce soit en plus).

À l’époque, la v3 était déjà annoncée, mais elle a mis énormément de temps à sortir. Ce retard a entraîné le départ progressif de nombreux développeurs de l’écosystème.

Pour autant, le projet n’en demeure pas moins sexy !

L’évolution d’un projet prometteur face à une concurrence féroce

Meteor.js avait, à ses débuts, tout pour casser la baraque. J’ai beaucoup d’amis qui s’étaient lancés à fond dans la techno, allant jusqu’à migrer leurs projets en cours vers Meteor.

Le concept était tellement novateur :

• du temps réel à tous les étages
• des applications ultra fluides

De quoi faire rêver tout développeur.

Meteor a longtemps été le framework préféré des prototypeurs. Non pas que la techno ne puisse aller plus loin que le prototype, mais surtout parce qu’elle permet d’aller très vite. Bien qu’avec une lourde charge, ses performances commencent à décliner.

Quand le combo Firebase/Angular a commencé à monter, beaucoup ont commencé à quitter le navire. Je pense que c’était surtout par volonté d’aller encore plus vite. Firebase, avec sa promesse de backend sans gestion complexe, a séduit pas mal de devs (qui, il faut le dire, sont souvent allergiques à tout ce qui touche de près ou de loin au système).

Avec Meteor, même s’il existe des services de déploiement comme Meteor Galaxy (pour l’app) et Mongo Atlas (pour la base), les coûts peuvent vite devenir dissuasifs. Beaucoup de startups ont cramé pas mal de cash sur ces services, espérant atteindre leur break-even rapidement.

Firebase, avec son approche low-cost, reste plus accessible. Même si vos charges explosent, vos coûts seront souvent bien inférieurs à vos revenus – à condition que votre app génère de l’argent (sinon… c’est du bénévolat 😅).

Le vrai déclin

Meteor a été pensé pour créer des SPA (Single Page Applications). Même si vous pouvez changer de vue, vous restez théoriquement sur un seul endpoint côté URL.

Autre point : Meteor n’utilise pas les API traditionnelles REST ou GraphQL par défaut (même si c’est possible via des extensions). Il expose des RPC (Remote Procedure Calls) : le frontend appelle une fonction côté serveur qui s’exécute et renvoie le résultat. C’est ainsi que vous interagissez avec la base de données et le backend, depuis la vue.

Meteor supporte plusieurs moteurs de rendu : Blaze, React ou Vue.

Il en fait des choses, ce Meteor, quand même !

Ce qui a littéralement enfoncé le clou pour Meteor, c’est la démocratisation de Next.js.

Même si les deux outils n’ont pas les mêmes objectifs, Next.js a su répondre à un autre besoin des devs : la gestion des routes dans les projets React.

On peut parler de l'arrivé du titan : Next.js

Next.js a apporté pas mal de nouveautés :

• rendu server-side
• optimisation SEO
• organisation de projet pour React

C’est d’ailleurs pour ça que ce blog tourne sur Next.js.

Mais entre nous, Meteor a toujours une place particulière dans mon cœur de développeur. Ce projet a une odeur de hack que j’aime particulièrement.

Pas un hack dans le mauvais sens du terme (bidouille), mais dans le sens d’un projet qui s’est construit comme un "hack propre", puis a été solidifié pour devenir un super outil – et permettre à d’autres de créer des super produits à leur tour.

En gros, la promesse de Meteor c'est : concentrez-vous sur le produit, il va faire le reste !

Du sang, des larmes et des lignes de codes

Le passage de Meteor 2.0 à Meteor 3.0 s’est fait dans la douleur. Le projet a été repoussé de nombreuses fois car le chantier était colossal. Sur Meteor 2.0, il n’y avait pas d’async/await ou de Promise intégrés dans le cœur du framework (vous pouviez en utiliser dans vos libs et votre code, mais pas via l’API Meteor elle-même).

Pour gérer l’asynchrone, les développeurs avaient écrit des wrappers qui simulaient l’async via des boucles, en attendant un état avant de répondre. C'est cela, le concept de fibers...

Oui, dit comme ça, ça paraît sale… mais en tant que dev, vous n’aviez pas à vous en soucier.

De mon côté, pendant longtemps, j’ai rafraîchi la page du projet en espérant voir apparaître la fameuse v3.0.

Et l'annonce était prometteuse:

• passage à Node v20 (au lieu de Node v14 dans Meteor 2)
• abandon de fibers côté serveur
• intégration de Mongoose par défaut
• support natif de TypeScript
• prise en charge des ES Modules
• meilleure intégration avec React et Vue
• mises à jour de sécurité
• utilisation de React Router DOM
• amélioration de la gestion des comptes…

Ça fait beaucoup de choses ! Pas étonnant que ça ait pris du temps. À un moment, j’ai complètement zappé… je suis passé à autre chose.

Jusqu’à un matin où je me suis dit : "Tiens, si j’allais checker ça ?"

Et là, surprise : Meteor 3.0 était sorti. Discrètement, sans même faire de bruit. Et c’est dommage : je pense que ce projet mérite clairement plus d’attention.

Meteor 3.0 en pratique

Je parle beaucoup, mais il fallait que je vous donne un peu l'historique de tout ceci. Que je vous parle de ce que représente Meteor pour moi.

Maintenant, passons à la pratique.

J'ai porté mon projet Trello simpliste de Meteor v2 à Meteor v3.

Voici le projet d'époque:

Que doit-on modifier ?

Je trouve que Meteor 3.0 par rapport à Meteor 2.0 est quasiment plug & play.

Avec un linter, vous verrez tout de suite ce qu'il faut adapter.

Les principaux changements concernent les appels à la base de données :

• .insert() devient .insertAsync()
• .update() devient .updateAsync()
• .find() reste .find()
• .remove() devient .removeAsync()
• etc...

Il y a sûrement d’autres changements, mais pour un petit projet comme celui-ci, je n’ai pas eu besoin de plus.

Autrement dit : vous n’avez aucune bonne raison de repousser votre montée de version 😄

Résultat

Pour célébrer cette montée de version comme il se doit, je me suis dit : autant en profiter pour refaire un peu le design vieillissant du projet.

J’utilise déjà Tailwind, donc il m’a suffi de changer quelques classes sur les composants pour rendre le tout un peu plus agréable visuellement.

Faisons simple:

Voilà, j’espère que cet article vous a plu.

N’hésitez pas à le partager !