Discussion :

[Arsene Newman]

Facebook délaisse le modèle MVC au profit de son propre modèle Flux
car MVC ne permettrait plus un passage à l’échelle suffisant

Facebook, le réseau social qui compte pas moins d’un milliard de comptes actifs, vient d’annoncer son passage au nouveau modèle de programmation Flux développé par ses soins, délaissant par la même occasion le modèle MVC, ce dernier n’étant plus adapté aux besoins du réseau social et de l’immense quantité de données transitant à travers lui.

En effet, durant la conférence des développeurs Facebook (F8), la session « Hacker Way : Rethinking Web App Development at Facebook » a traité la problématique du modèle le plus adapté à Facebook, Tom Occhino, ingénieur chez Facebook, a alors déclaré que « MVC est devenu compliqué très rapidement ». Il a conclu par la même occasion que MVC ne leur permettait plus un passage à l’échelle conséquent vu leur importante base de données.

Il a donné d’autres détails sur le cheminement de cette décision et a expliqué que la complexité du modèle se faisait ressentir à chaque introduction d’une nouvelle fonctionnalité, le code était devenu fragile, dès lors cette situation est devenue problématique et les ingénieurs craignaient de plus en plus de comportements hasardeux de l’ensemble.

Ainsi, l’une des solutions qui ont été retenues par les ingénieurs est l’utilisation du nouveau modèle Flux qui est caractérisé par un flux de données unidirectionnel. Ce dernier a été conçu autour du framework Javascript React qui est utilisé par Facebook pour construire des UI web prédictibles et déclaratives.

Jin Chen, ingénieur logiciel chez Facebook, a expliqué de son côté que le modèle Flux doit être vu comme un modèle unidirectionnel (pas de communication bidirectionnelle entre les entités du modèle) composé de trois entités : Dispatcher, Store et View.

Le store contient toutes les données d’une application, le dispatcher (correspondant au Controller de MVC) se charge d’accepter ou de refuser des mises à jour à appliquer au Store suite au déclenchement d’une action, ainsi il peut bloquer le déclenchement de certaines actions pour ne pas perturber l’état du Store ou encore décider de l’ordre d’exécutions des actions. Quant au View, il se met à jour lorsque le Store change et peut éventuellement lancer une action, ce qui lui permet d’interagir indirectement avec le store.

Ce modèle permet donc de simplifier la maintenance et le debug des applications pour les nouveaux développeurs et se montre particulièrement intéressant pour contenir les actions qui peuvent avoir des effets de bords aux conséquences inattendues. En outre, il a permis à Facebook de corriger un bug de son application de chat.

Source : facebook.github.io

Et vous ?

Que pensez-vous du nouveau modèle Flux ?

Pensez-vous que le MVC ne soit pas le plus adapté pour le passage à l’échelle ? Pourquoi ?

[rawsrc]

J'ai écouté entièrement le topo et je dois dire que c'est une approche technologique très intéressante.
Je pense quand même qu'il faille derrière du lourd question serveurs.

Quelques points :
- diminution drastique de l'abstraction
- focus sur les fonctionnalités et beaucoup moins sur leur implémentation technique au sein d'un existant
- architecture ouverte et évolutive par défaut (y a qu'à regarder la convergence de tous les services FB vers un seul et unique modèle de codage : React)
- Au temps 40:30, ils enterrent clairement AngularJS
- Se positionnent comme les successeurs naturels de jQuery

Si on rajoute à ceci ce que Facebook fait autour du PHP, ils vont finir à terme par proposer un environnement de développement complet couplé à un environnement technique de très haute performance et tout ça en open-source.

En un seul mot : impressionnant.

C'est des p'tits jeunes qui n'en veulent

[super_navide]

Je pense la meilleur solution est quand même le MVC mais structuré de la façon suivante :
d'un coté VC et de l'autre M.
Ensuite on décline avec les technos suivantes pour le VC (Vue controleur ) on utilise du javascript , du HTML et des CSS fournit par un serveur HTTP simple pas de génération de page comme JSP GSP ASP PHP
De l'autre un serveur de service attaqué par des services au format HTTP via AJAX coté navigate.
On modélise les services métier en premier puis l'interface utilisateur.

[thebronx]

Intéressante approche , à expérimenter.
Après Je verrai si je l’adopte ou pas .

[leminipouce]

- Au temps 40:30, ils enterrent clairement AngularJS

Enterrer AngularJS de Google quand on s'appelle FB... presque normal

Je pense la meilleur solution est quand même le MVC...

Meilleure solution pour quoi ? Pour tout ? Une solution pour les gouverner tous et dans les ténêbres... Oh pardon, je m'égare.

Même si je n'ai que 10 ans d'expérience, je n'ai encore jamais vu une solution unique, un langage unique, une architecture unique etc... qui surplante tous les autres sans exception et qui réponde universellement à tous les besoins...

J'ai comme envie de dire que chez FB ils n'embauchent pas que des brêles et que dans le tas il doit bien y en avoir 1 ou 2 qui a réussi à réfléchir à la solution la plus adaptée à leurs besoins, avec les moyens actuels...

[super_navide]

Je pense quand même pour les IHMs (hors jeux videos en 3D et encore il y a des démos WEBGL bleufante qui laisse penser que les jeux web on un bel avenir ) le mieux
est HTML5-JAVASCRIPT et CSS apres pour créer des services appelé en AJAX de puis le client il n'y a pas de langage unique tous dépend de l'existant , des besoins de performance etc..

[SylvainPV]

J'aime beaucoup les diagrammes qui font croire que tout est plus simple en retirant les noeuds On passe de 7 vues à une seule, et on cache toute la complexité des règles métiers et gestion de droits dans la case "Store" qui devient le point de concentration de cette organisation.

Facebook paie une petite fortune une armée d'ingénieurs tous très jeunes et talentueux pour réinventer la roue, en mieux bien sûr. Certaines de leurs idées sont réellement novatrices et intéressantes à creuser, notamment sur React, mais du reste c'est énormément de com et d'étalage technologique pour attirer les développeurs (et là clairement, on sent l'effet de concurrence avec Google). Une communication unidirectionnelle et un dispatcher, ce n'est pas sans rappeler toutes les solutions existantes orientées autour de la prog évènementielle. J'y vois surtout une grosse couche de refactoring bien préparé, comme doit y passer n'importe quel service Web ayant subi des évolutions incrémentales depuis des années.

[leminipouce]

Je pense quand même pour les IHMs le mieux est HTML5-JAVASCRIPT et CSS ...

C'est pas un modèle de développement ça, ce sont des langages !

[steel-finger]

C'est une approche très intéressante, qui est à testé

[Yoann29]

Avec de beaux slides, leur approche semble implacable ! Pourtant à y regarder de plus près, en se basant sur un dispatcher,
leur modèle semble davantage tendre vers un autre modèle du GOF : le pattern observer.

Les technologies employées présentent tout de même une approche très intéressante, mais cela s'apparente davantage à une opération de communication
vantant les mérites de leurs framework maison (un peu comme thrift pour les webservices)

[r0d]

Facebook paie une petite fortune une armée d'ingénieurs tous très jeunes et talentueux pour réinventer la roue

Peut-être, mais je suis d'accord avec eux que le modèle MVC a ses limites, et qu'il serait intéressant de réfléchir à d'autres modèles. J'ai déjà eu l'occasion d'en parler sur le forum C++, et la façon dont mes remarques ont été reçues m'ont rappelé à quel point il est difficile de s'attaquer de front à une doxa bien établie. MVC est tellement présent partout que c'en est devenu un dogme. Tous les frameworks se basent sur MVC (de .Net à Qt en passant par Swing, etc, etc, ça devient une religion, je n'aime pas trop ça.

[Tcharl]

Il ne se sont pas trop foulés, il ont réinventés struts 1 ... Congrats!

[acx01b]

quelle différence entre MVC et ce modèle FLUX ?

Parce que le schéma donné pour MVC est gentil mais les liens Vue --> Modèle, beaucoup sont du code. Souvent un événement sur un objet 'vue' appelle plus ou moins directement une méthode d'un objet 'modèle', ces méthodes peuvent être assez complexes et donc on ajoute un objet qui fait le lien Vue --> Modèle, ce qui est exactement le schéma FLUX mais avec des liens multiples (de toute façon c'est forcément des liens multiples, même si dans beaucoup de cas avec l'héritage on peut rendre ça un peu moins fouillis).

Sans parler du fait que beaucoup d'objets modèle quand on code en MVC sont en fait des objets qui gèrent des liens compliqués Vue->Modèle, ces objets peuvent donc être facilement déplacés dans la catégorie Action.

[gabriel.klein]

Le modèle qui va le mieux je trouve pour les applications web.

[ Data ] -> [ Controller ]-> [ API, Auth ] -> [ Cache / Refresh ] -> [ View ]
\---- [ Listener, Event dispatcher ] ------------/

J'expose mes données au travers d'une API, tout passe par l'API.

J'écoute les modifications que je transmet au travers d'un "event listener". Exemple: Dit-moi si l'utilisateur lambda a été modifié.

[Cache et View] se trouve au niveau de l'applicatif. Je prend les données du cache, et derrière (si besoin) je vais lancer un refresh.

Mes données ont un seul identifiant global. De plus elles ont une date d'expiration.

Ce qui justifie ce modèle:
Parfois je veux la dernière version d'une donnée. Exemple mon panier d'achat!
Parfois une version qui a quelques heures est suffisante. Exemple la description de profile d'un ami. Le DNS d'un site.
Parfois je veux "pousser" de l'information au client. Exemple: votre document exel a été mis à jour. Pour simplifier simplement pousser l'identifiant (unique) qui a été changé suffit

C'est assez efficace.

Le traditionnel MVC ne marche pas sur le net pour les nouvelles applications! La "view" étant au niveau du client, le model et le controller au niveau du serveur.
Et surtout on a différentes "views"! Une application mobile, une application web, un service externe.

De plus on a souvent plusieurs sources de données. Intégrer Facebook est un exemple.

[Greg-dev]

Personnellement je ne vois pas en quoi Facebook délaisse le modèle MVC, je dirai plutôt qu'il l'applique comme il le devrait :
- Avant : le model échange avec la vue, pour moi il y a une couche entre les 2 et pas à côté
- Après : View -> Action / Dispatcher -> Store, on dirait du MVC LOL

[tse_jc]

Bonjour,

Leur diagramme initial sur la structure MVC ressemble plus à du MVVM qu'à du MVC, MVC dans lequel normalement la vue n'est pas censée communiquer directement avec le modèle, sans parler que le bloc action à gauche est censé être issu de la vue. Leur modèle Flux ressemble plus pour moi à ce qui est fait chez nous, à savoir, comme j'aime à le qualifier du MVC-OVP c'est à dire du MVC Orienté Vertical Process. Par rapport à ça, je rejoinds assez les conclusions portées par rawsrc.

A gabriel.klein: concernan la meilleure architecture web, tout dépends si on pilote les données au niveau SGBDR ou au niveau Serveur Tiers. Il faudrait aussi tenir compte des conclusions de la maîtrise d'ouvrage d'une appli, pour pouvoir en juger. De plus, et en général, il est plus sage et perenne de piloter les données au niveau SGBDR.

Parfois je veux "pousser" de l'information au client. Exemple: votre document exel a été mis à jour. Pour simplifier simplement pousser l'identifiant (unique) qui a été changé suffit

Je préfère personnellement la notification asynchrone (ex mail) comme le fait par exemple ce forum lorsque l'on suit une discussion et que quelqu'un en a modifié le contenu. Sinon le client en est informé lorsqu'il accède à la ressource par défaut. C'est aussi pertinent et performant, cela à le mérite aussi de laisser la main au client pour choisir s'il souhaite en être averti lorsqu'il ne travaille pas dessus, et donc de ne pas monopoliser des ressources inutilement, dans le sens où cela peut parfois être mal perçu, sauf si c'est une exigence applicative bien entendu.

Cordialement,

[souviron34]

j'vais encore faire mon vieux croûlant mais bon, c'est un peu ce que je dis dans ces colonnes depuis 2007...

D'un seul coup ça a été la religion... Alors que les clients/serveurs, les grappes, etc, ça faisait belle lurette que ça exitait..

Là on a appliqué ça partout, sans discernement... Bref, bien évidemment que c'est limité... Faut pas être un super-héro pour comprendre ça..

Mais il parait que le bon sens se perd mon brave monsieur.. Ben en fait, au bout de X années, il revient