Topics

Featured in Development

Alex Bradbury gives an overview of the status and development of RISC-V as it relates to modern operating systems, highlighting major research strands, controversies, and opportunities to get involved.

Featured in Architecture & Design

Will Jones talks about how Habito, the leading digital mortgage broker, benefited from using Haskell, some of the wins and trade-offs that have brought it to where it is today and where it's going next. He also talks about why functional programming is beneficial for large projects, and how it helps especially with migrating the data store.

Featured in AI, ML & Data Engineering

Katharine Jarmul discusses research related to fair-and-private ML algorithms and privacy-preserving models, showing that caring about privacy can help ensure a better model overall and support ethics.

Featured in Culture & Methods

This personal experience report shows that political in-house games and bad corporate culture are not only annoying and a waste of time, but also harm a lot of initiatives for improvement. Whenever we become aware of the blame game, we should address it! DevOps wants to deliver high quality. The willingness to make things better - products, processes, collaboration, and more - is vital.

Featured in DevOps

Service mesh architectures enable a control and observability loop. At the moment, service mesh implementations vary in regard to API and technology, and this shows no signs of slowing down. Building on top of volatile APIs can be hazardous. Here we suggest to use a simplified, workflow-friendly API to shield organization platform code from specific service-mesh implementation details.

Facebook: MVC Does Not Scale, Use Flux Instead [Updated]

This article has been updated based on community and Jing Chen (Facebook)’s reaction. (See the Update section below.)

Facebook came to the conclusion that MVC does not scale up for their needs and has decided to use a different pattern instead: Flux.

During the recent F8 session Hacker Way: Rethinking Web App Development at Facebook, Tom Occhino, Engineering Manager at Facebook, said that for their “sufficiently” large codebase and large organization, “MVC got really complicated really quickly,” concluding that MVC does not scale. The complexity of the system went exponential every time they attempted to add a new feature making the code “fragile and unpredictable.” This was becoming a serious problem for developers new to a certain codebase because they were afraid to touch the code lest they might break something. The result was MVC was falling apart for Facebook.

A fix for this problem required to “structure the code in a way that makes it more predictable.” This has been done with Flux and React. Flux is a system architecture that promotes single directional data flow through an application. According to Occhino, React is a JavaScript framework for building “predictable” and “declarative” web user interfaces that has enabled Facebook to move faster in developing web applications.

Jing Chen, Software Engineer at Facebook, added that MVC is good for small applications, but the complexity explodes when many models and their corresponding views are added to a system, as shown in the following slide:

Such an application would be difficult to understand and debug especially due to the possible bidirectional data flow between models and views, according to Chen, proposing instead the following Flux design:

The Store contains all the application’s data and the Dispatcher replaces the initial Controller, deciding how the Store is to be updated when an Action is triggered. The View is also updated when the Store changes, optionally generating an Action to be processed by the Dispatcher. This ensures a unidirectional flow of data between a system’s components. A system with multiple Stores or Views can be seen as having only one Store and one View since the data is flowing only one way and the different Stores and Views do not directly affect each other.

The dispatcher is the central hub that manages all data flow in a Flux application. It is essentially a registry of callbacks into the stores. Each store registers itself and provides a callback. When the dispatcher responds to an action, all stores in the application are sent the data payload provided by the action via the callbacks in the registry.

As an application grows, the dispatcher becomes more vital, as it can manage dependencies between stores by invoking the registered callbacks in a specific order. Stores can declaratively wait for other stores to finish updating, and then update themselves accordingly. …

Stores contain the application state and logic. Their role is somewhat similar to a model in a traditional MVC, but they manage the state of many objects — they are not instances of one object. Nor are they the same as Backbone's collections. More than simply managing a collection of ORM-style objects, stores manage the application state for a particular domain within the application.

What is important, said Chen, is for the data layer to complete its update of the view before any other action is triggered. The Dispatcher can be made to reject actions while it has not finished processing a previous action. This design is especially helpful for actions that have side effects such as updating other views, making the code more clearer, easier to understand and debug by new developers. Flux helped Facebook eliminate a chat bug that informed users they have a new message when it was not the case.

While Facebook can use any design they seem fit, a question remains. Does MVC scale or not? After all, there are many websites out there that scale.

Update. After publishing this article, many developers have commented on Reddit regarding Facebook’s take on MVC. Here are some of the comments, some considering that Facebook is misusing MVC in the first place while others considering they are doing the right thing:

For one, their MVC Graphic is insanely flawed. They are depicting a single controller to handle multiple models, when you'd almost certainly want to separate out controllers based on either what model they interact with, or other logical divisions.

Of course a setup like what they described wouldn't work, but it isn't really MVC either.

If you compared their flux diagram to an actual MVC diagram like this you'd get a much clearer picture that there's nothing inherently wrong with MVC for web apps.

It seems that this architecture is shifting MVC to something that looks event-based. "Stores" register themselves (and presumably any call-order dependencies) with the dispatcher, and the dispatcher processes actions and ensures that the correct chain of calls are made. This moves the burden of ensuring proper call-order from controllers to the dispatcher and store. This should reduce the necessary comprehension to modifying behavior.

My takeaway from just glancing at this, although I don't think I understand it particularly well yet, I think I understand and agree with the the general idea.

The Reddit user jingc09, who seems to be Jing Chen based on her comments, added some replies:

jingc09: Yeah, that was a tricky slide [the one with multiple models and views and bidirectional data flow], partly because there's not a lot of consensus for what MVC is exactly - lots of people have different ideas about what it is. What we're really arguing against is bi-directional data flow, where one change can loop back and have cascading effects.

One thing I want to clarify is that the dispatcher doesn't play the same role as controllers. There's no business logic in the dispatcher, and we use the same dispatcher code in multiple applications. It's just a central hub for events to reach interested subscribers (usually stores). But it's important in Flux because that's where the single-directional data flow is enforced. …

A controller can send commands to the model to update the model's state (e.g., editing a document). It can also send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document).

Based on the Reddit comments, there seems to be some confusion on what MVC is and how it should be implemented.

Regarding Facebook’s take on MVC we have two observations:

1) The first slide seems really blown up with too many models and views, making one wonder if there is something like that in the real life. The problem that Facebook addressed with Flux was the chat app which had 3 views.

2) Why is View generating a data flow creating thus the bidirectional flow in their MVC example? And why is View generating an Action in the Flux diagram? A View shouldn’t generate anything. A View is just a "view", nothing else. Is Facebook misusing MVC?

Misunderstood

Your message is awaiting moderation. Thank you for participating in the discussion.

I think people are misunderstanding the example diagrams completely. These are not anywhere near an exact depiction of what Facebook uses. The MVC diagram shows what is called a facade controller. It is there for illustration purposes.

It's no suprise Facebook deems MVC unscalable.

Your message is awaiting moderation. Thank you for participating in the discussion.

Given their blatant abuse/misuse of MVC it's truly not a surprise that they consider it unable to scale. I never would have imagined a company like Facebook would so blatantly misuse a development pattern like this. I shudder to imagine what their code base looks like. As a developer who happens to build applications that reside exclusively on Facebook, I'm starting to see why we have so many problems with stability and random exceptions being thrown when making calls the various end points on their API, especially the Ads API. I've never worked with a platform so unstable that integration tests will fail randomly, but will pass again if a few minutes go by and the very same test is executed with no changes what so ever. Really all I can say about this article just simply: Wow just... wow. *shaking head*

TASKS?

Your message is awaiting moderation. Thank you for participating in the discussion.

There is a simple reason as to why MVC does not scale. Everything we do is a "task". A task has a simple lifecycle:- enabled/(assigned)/disabled (not all tasks can be performed at any time)- started- completed

MVC offers no relationship to the underlying tasks and their lifecycle. All task boundaries and lifecycle need to be coded within controllers, the views and to a certain extend the models. That's what's not scalable in any way when you use MVC. Your code explodes with task boiler plate code and becomes unmaintainable very quickly because of its stateful nature. Hence, I am not sure Flux solves anything with that regard.

Misleading diagrams

Your message is awaiting moderation. Thank you for participating in the discussion.

I have to say that the diagrams shown here are really misleading, or partially wrong.

We all may know that a view, once triggered a specific action, may have two major possibilities:1. To update some UI elements locally, without any interaction to the backend; or2. To perform necessary interactions to the backend which definitely will go through another typical processing, like controller->model->view, or the equivalent.

We may have found that in the Facebook version of diagram, the view is pointing to the action (controller?) and redirecting to the model (ok, they rename or redefine another misleading concept here, say store). That's exactly the process of abovementioned #2.

In short, Facebook is misleading the readers by a wrong MVC diagram but trying to illustrate why Facebook is right by sharing right MVC diagram with "proprietary" diagrams and concepts.

Misleading diagrams

Your message is awaiting moderation. Thank you for participating in the discussion.

I have to agree with this. I have never seen an MVC diagram that looked like *that* :)

When the code samples came up the immediate problem appeared to be high coupling where a single handler tried to juggle too many views/models.

An event-based de-coupled approach is what large applications require. In that way even highly cohesive, isolated MVC structures (or anything really) would shine.

But the fact that they fixed their coupling and then decided to attribute the success to a 'new' architecture does seem somewhat weird. Change 'dispatcher' to 'controller' and 'store' to 'model' and you have a flavour of MVC.

MVC is an architectural pattern, not an implementation

Your message is awaiting moderation. Thank you for participating in the discussion.

To suggest MVC does not scale is like saying RESTful services or n-tier systems don't scale, which makes no sense since scalability comes down to implementation strategy, not style. If the diagram above reflects Facebook's version of MVC, the implementation is where they messed up; non-specialized controllers? no link between controller and view for page rendering? I'm going to assume the diagram did not come from FB and is there for illustration purposes, nevertheless, the premise of the argument is wrong. Unless we see FB's implementation of MVC, and where it broke down, it's difficult to see how flux addressed MVC issues in the first place.

MVC / OOP is not for the web.

Your message is awaiting moderation. Thank you for participating in the discussion.

Websites and web applications are a totally different ballgame. There seems to be a huge misconception that web apps, because it has the name app in it, should be built like a console, or OS application. Here's a new way to do true web application development. Check out the ajax-controller, which is really the dispatcher for any AJAX style actions.

I got into Flux the wrong way..

Your message is awaiting moderation. Thank you for participating in the discussion.

When I was reading up on communicating React components that are siblings of each other, a recommendation was to use Flux as a way to keep track of all the changes happening. Now I'm reading about Flux as this whole architectural system that I need to leach onto my own application? I got into React only because it's non-interfering with my project, and it seems Flux is interfering. The way I've always used MVC, is 1 view, that uses 1 model, that uses 1 controller. If I want another view, I create another model and controller. You CAN'T get simpler than that. There's really nothing wrong with too many controllers, too many views (or partial views), and too many models. They all share a single responsibility that is clear. Flux does this. When I saw the Flux diagram, that is EXACTLY how I used MVC! So why am I looking at this in the first place? If you're using ReactJS for non-interfering reasons, why should I incorporate interfering reasons like Flux?