Everything You NEED to Know About Client Architecture Patterns

Animation tools: Adobe Illustrator and After Effects.

Checkout our bestselling System Design Interview books:

ABOUT US:
Covering topics and trends in large-scale system design, from the authors of the best-selling System Design Interview series.

[editin]

Amazing video for people that already understand what you're talking about.

[hrishabhg]

The video should have given examples like what django follows, what react follows etc. in reverse way so we can connect better. Otherwise there is too much overlap based on definition itself.

[FolkOverplay]

Nice collection of the different patterns. I appreciate short content but this was a little bit too short. It makes it very hard to understand the difference between the patterns. Especially MVC and MVP but it's hard to understand the difference between most of them.

[suvetar]

About time I found a video that explains it properly, I've been coding for 35+ years now and have been following MVP/Viper style for quite some time, just I
didn't know those patterns already had a name!
Thanks for this my Dude!

[troooooper]

Summary: they are all the same... just different words... code need to update view, store data, and act on data. how you spread it or what you call doesn't matter.. No matter how complex your app is there are still 3 fundamental parts.

[ShreksSpliff]

Thank you for your time. I enjoy the videos and you're patience in them.

[ivanshuba]

Excellent! In my experience, nobody ever was able to explain this subject so clearly. Additional thanks for the diagram at the beginning of the video. It explains everything perfectly by itself.

[TimnewCNYN]

I think the video missed the most critical differences between these patterns: What is a View.

Video mentioned in all these patterns, there is always the concept of View, and this is somehow treated as a common feature across these patterns.
But to me, this is actually the no.1 differences between these patterns.

For MVC, View is typically Model aware, and it typically extract data from model directly. So it typically requires a template engine to some kind of data binding mechanism to achieve that. Or it will lead to an even more bloated Controller in practise. In MVC, view is typically one off thing, Controller creates the view, update is typically done by recreate the view or rebound all the values again if the view isn't created by controller. MVC is typically used by http server, but also some UI frameworks, such as Cocoa/CocoaTouch (I would say Apple UI framework is more a MVC/MVP hybrid)

MVP was created to reduced the Model View coupling, by introducing a dedicated Presenter in the middle, so the View can be completely decoupled from Model. And also Presenter can be used to not just creating the View but also used to update the View, when data changed, which allow a more granular control of the View. such as partial update. And View is kind of reused, and keep being updated. (Typically used by last gen UI framework, like Android or iOS, or WinForm is also kind of this type) MVP allow View to be provided by UI framework, and completely focused on rendering, and is business logic free.

MVVM was introduced due to App is moving a bit more to the data driven way again. Like MVC, View in MVVM is again model aware and is capable for data binding. But data binding here is tends to be logic-less and lightweight, so it doesn't have or tend to not have the data projection capability. So the data projection logic to convert the raw data into presenting ready data is then hosted in ViewModel, and View is bound to ViewModel instead of Model.

MVVM-C is just a variation of MVVM, a hybrid of MVVM to MVC, Coordinator is like the old Controller, oversees the lifecycle, navigation or other admin responsibilities.

VIPER, I'm not sure this is a widely used term, but again it is just a MVVM variation, it has Router, pretty much a controller but more focused on navigation and lifecycle management. Presenter is similar to ViewModel is the View has data binding capability or become MVP presenter when View doesn't have data binding capability. Interactor is an action model that extract the business logic from the model (to avoid ActiveModel pattern, which is considered as anti-pattern by a certain group of people), and interactor allow to to involves more external resources rather than just model. Interactor has a more passive version which is typically called UseCase.

So above all, per me, the major difference between MVC, MVP, MVVM is the caused by responsibility of View.
MVC: View creation is relatively cheap, creating custom view is relatively cheap, so developer bind data to view by creating data aware custom views. user interaction on view is typically simple. Typically HTTP server.
MVP: View is created and updated, and View is provided by UI framework, and user creating custom view is expensive, so developer write Presenter to bind data to view, and update the view when data changed.
MVVM: Move to the data driven way, Update is done by UI Framework by tree diff, normally the View created here isn't the real render object. View is typically a layer of pseudo element. Mostly mordern UI framework, such as React, SwifUI, Jetpack Compose, Flutter. But also could be some old fashion framework, such as .net WPF....

[SDFC]

It'd be nice to also cover the Observer pattern (which is the source of those "update" and "notify" words).
In fact, the observer pattern was first used for implementing Smalltalk's MVC based user interface library.

Or, also discuss one-way data binding (ReactJS) vs. two-way data binding (Angular) 🙂

You could even cover client-side frameworks (e.g. ReactJS, Angular) vs server-side frameworks (e.g. JSP, Laravel, Rails, NextJS) vs what Svelte is doing. Just some topic ideas for other shorts you could make 😁

[hendrikmartina]

I was hours ago studying this topic. What a great timing!!! Thank you for covering this topic

[VladimirMinkin]

There are different types of model - active (mvc) and passive (mvp), in these types view can't change data directly, but in mvvm view can, side effects also possible (adding c to equation).

[RicoGrof]

I think core of all is just Input Process Output. when pattern getting bigger we separate Process again into other Input Process Output. until we reach S (Single Responsibility) from SOLID.

[sudhanshuyadav]

The key takeaway from this video is Delegation. The Model(M) and View(V) will always be constant in any of the Client Architecture Patterns, the Controller(C) will start delegating the overload as our app becomes more and more complex.
Keep this in mind, you can always start with MVC and end up in VIPER depending on your app's complexity and requirement phase.
Architecture is always evolving in nature.

[nishaantdixit]

So basically it's invented language used by Non Coders to say the same thing i.e. Break down logic into presentation, BLOC and Repo?

[adilsheikh]

In VIPER presentation, pls correct 'Entily' to 'Entity'
I always wonder how you present the tons of knowledge so simply with such excellent presentations. Appreciate your efforts.
I believe, people should understand the requirements first & understand the usage patterns, before picking any pattern.
In fact, I think patterns will be coming to picture naturally if the development is done with open minds & not like 'My way or Highway'
That way a project will be a good one to work for, but it may cause many other projects to shutdown, as in many projects work is done like anything in the name of coding, development, innovation & what not....
By watching your videos, people fake a lot during System Design interviews...in the name of 'Back of the Envelope' calculations, these people give any numbers & then present the design what they have seen over the internet...I believe if someone ask the relation between their numbers & designs then most candidates will be blank.

[robottrainer]

MVVM, MVVM-C is standard for angular, react, vue frameworks. Keyword reactive programming/data-binding.

[yinglaoliu]

React Native with GraphQL tends to follow a component-based architecture with a focus on the UI and state management being closely integrated, rather than fitting into traditional architectures like MVC, MVP, MVVM, or VIPER.

[soblssk]

it's very clear, although i still don't understand it, thank you.

[faiyafxmedia]

This was a very good explanation video, thanks!

[tomross]

You argued that it’s about app size. I think it’s better to think of team size. The more complex the pattern, the better to work concurrently on different parts of the app. And vice versa: If you spend your lifetime working alone or in a team of two on an app, none of the patterns will give you a boost in productivity or quality.