Discussion :

[Coriolan]

JavaScript : Twitter a transféré tout son trafic mobile vers un nouveau stack
Node.js, Express et React

Un développeur de Twitter a publié un tweet indiquant que le réseau social a transféré tout son trafic mobile vers un nouveau stack Node.js, Express et React PWA. Toujours selon l’employé du réseau social, l’équipe de développement a travaillé pendant près d’une année pour assurer cette transition.

La pile JavaScript de Twitter a été en production depuis neuf mois, a dit Nicolas (pseudonyme du développeur). Lors des deux dernières années, l’architecture servant les visiteurs déconnectés a été composée de Scala, Google Closure Templates, et un peu de JavaScript. Il y a quelques mois, un développeur front-end de Twitter a commencé à tester Node.js avec une fraction de ces utilisateurs. Enfin cette semaine, un autre développeur a finalisé le transfert de l’ensemble du trafic vers l’application JavaScript.

L’équipe de développement n’a pas laissé tomber Scala pour le côté serveur, il s’agit juste d’une implémentation de Node.js en tant qu’intermédiaire entre le front-end et le back-end. Cette approche dite BFF (Backend For Frontends) a quelques avantages notamment au niveau de la performance. Au lieu de communiquer avec l’ensemble des services du back-end, chaque application client à un serveur d’orchestration qui reçoit tous les appels.

Évolution de Twitter

Lors de ses débuts en 2006, Twitter avait utilisé Ruby on Rails pour son stack back-end. Rails est un framework web libre écrit en Ruby. Il suit le motif de conception modèle-vue-contrôleur aussi nommé MVC. En tant que framework, il propose une structure au programmeur qui lui permet de développer plus vite et plus intuitivement.

En 2008, le réseau social a dû implémenter Memcache et Redis pour faire face à des problèmes de performance. Mais c’est à partir de 2009 que la base d’utilisateurs du site a littéralement explosé favorisée par plusieurs évènements comme la coupe du monde de 2010. Cette augmentation massive des visiteurs a révélé de graves problèmes et défis de l’architecture du réseau social. Elle était fragile et les développeurs se plaignaient d’une API lente du service. Le service devait ajouter plus de serveurs pour répondre aux requêtes de plus en plus nombreuses et garder la performance du site. Au lieu de se consacrer au développement et à l’implémentation de nouvelles fonctionnalités, les développeurs étaient dans l’obligation de faire un compromis entre flexibilité et performance.

Évolution du nombre d'utilisateurs de Twitter depuis son lancement

Le nombre d’utilisateurs continuait de croitre rapidement, pour cette raison, les ingénieurs ont décidé d’explorer de nouvelles voies d’optimisation de l’architecture du site. Ils se plaignaient surtout de problèmes de scalabilité de Rails. Après avoir testé JVM un moment, ils ont été éblouis par le niveau de performance atteint.

Rails est une solution parfaitement évolutive aujourd’hui, mais ça ne veut pas dire qu’elle peut magiquement s’adapter pour chaque type d’application donné. Contrairement aux idées reçues, Twitter n’est pas passé à Java, mais plutôt à Scala qui est prévu pour être compilé en bytecode Java (exécutable sur la JVM). Il faut savoir que Scala est parfaitement adaptée pour les services de messagerie en temps réel qui fonctionnent un peu comme Twitter.

L’utilisation de Rails au début de Twitter était-elle une erreur ?

Le passage de Twitter d’une technologie à une autre est souvent mal interprété par les observateurs. Beaucoup pensent que le réseau social a fait une erreur lorsqu’il a opté pour Rails lors de ses débuts. Bien évidemment ces dires ne tiennent pas, parce que le réseau social tel qu’il est aujourd’hui est radicalement différent et a donc besoin de différentes technologies.

Twitter a été lancé par deux personnes et la première version du site a été développée en quelques jours seulement. Ils avaient besoin d’une plateforme qui devait avoir un rendement considérable compte tenu des heures de développement investies. Cela leur a permis d’introduire des changements rapides pour répondre aux besoins des utilisateurs, car il n’avait aucune idée sur l’évolution à long terme de leur jeune plateforme. L’engouement pour Twitter était là, mais personne ne savait quelle direction prendre.

Quelques années plus tard et les choses ont changé pour l’équipe de développement. Maintenant que le produit est plus stable et ne change plus au même rythme, leur principal souci aujourd’hui est de gérer l’énorme pression sur le service. La mise à jour en temps réel de la fonctionnalité de recherche par exemple a eu un vif succès que personne n’a anticipé.

Alors que Scala/Java est probablement adapté aux besoins de Twitter aujourd’hui, il aurait été inconcevable de l’utiliser dès le début de la plateforme pour plusieurs raisons. De un, Scala a été encore jeune et immature et parce qu’aussi Java n’aurait pas pu donner la flexibilité et l’agilité assurées par Rails.


Source : Twitter

Et vous ?

Qu'en pensez-vous ?
Est-ce que vous aussi votre entreprise a migré vers JavaScript côté serveur ou pas ?
Que pensez-vous de la performance de Node.js et Angular ?
Est-ce que vous aussi vous avez trouvé Ruby on Rails peu performant ? Si oui, qu'avez-vous utilisé ?

[Tsilefy]

Rails était bien sûr le bon choix pour faire du RAD/prototypage, terminer rapidement une application fonctionnelle, avec une main d'oeuvre relativement abondante (comparé à Scala). Il faut juste savoir évoluer son stack en fonction des besoins, et c'est ce qu'ils ont fait.

Le principal intérêt de cette migration, c'est que c'est une pub énorme pour les Progressive Web Apps dans la lutte natif vs web apps.

[bdavidxyz]

Conclusion toujours vraie en 2017 : il faut presque toujours se lancer avec Rails avant de penser aux technos plus "à la mode". D'abord vérifier que ça marche commercialement avant de penser perf.