IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Arsene Newman

48PARTAGES

6  0 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 19/05/2014 à 15:47
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.
5  0 
Avatar de leminipouce
Membre éprouvé https://www.developpez.com
Le 19/05/2014 à 16:15
Citation Envoyé par super_navide Voir le message
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 !
2  0 
Avatar de leminipouce
Membre éprouvé https://www.developpez.com
Le 19/05/2014 à 15:24
Citation Envoyé par rawsrc Voir le message

- Au temps 40:30, ils enterrent clairement AngularJS
Enterrer AngularJS de Google quand on s'appelle FB... presque normal

Citation Envoyé par super_navide Voir le message
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...
1  0 
Avatar de acx01b
Membre averti https://www.developpez.com
Le 20/05/2014 à 13:12
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.
1  0 
Avatar de gabriel.klein
Membre régulier https://www.developpez.com
Le 21/05/2014 à 8:39
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.
1  0 
Avatar de thebronx
Membre à l'essai https://www.developpez.com
Le 19/05/2014 à 13:24
Intéressante approche , à expérimenter.
Après Je verrai si je l’adopte ou pas .
0  0 
Avatar de Yoann29
Membre du Club https://www.developpez.com
Le 20/05/2014 à 10:17
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)
0  0 
Avatar de Tcharl
Membre averti https://www.developpez.com
Le 20/05/2014 à 11:59
Il ne se sont pas trop foulés, il ont réinventés struts 1 ... Congrats!
1  1 
Avatar de Greg-dev
Membre régulier https://www.developpez.com
Le 23/05/2014 à 9:24
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
0  0 
Avatar de tse_jc
Membre confirmé https://www.developpez.com
Le 24/05/2014 à 0:51
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,
0  0