Everything You NEED to Know About Client Architecture Patterns
Вставка
- Опубліковано 8 січ 2024
- Get a Free System Design PDF with 158 pages by subscribing to our weekly newsletter: bytebytego.ck.page/subscribe
Animation tools: Adobe Illustrator and After Effects.
Checkout our bestselling System Design Interview books:
Volume 1: amzn.to/3Ou7gkd
Volume 2: amzn.to/3HqGozy
The digital version of System Design Interview books: bit.ly/3mlDSk9
ABOUT US:
Covering topics and trends in large-scale system design, from the authors of the best-selling System Design Interview series. - Наука та технологія
Amazing video for people that already understand what you're talking about.
Thank you for your time. I enjoy the videos and you're patience in them.
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.
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.
I was hours ago studying this topic. What a great timing!!! Thank you for covering this topic
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.
Simply beautiful as always.
greatest videos so far.. my kids 7 years also understood
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).
Great series, thank you.
The BEST explanation.
Your explanation is very clear and short. This is what makes you stand out to me.
Always eager for your content.
Love this video. I always confuse MVC and MVP. The approach is so similar...
Yep. Even with the video these concepts are still confusing for being too similar to each other. But, the takeaway is that in MVC, the controller is in charge, while in MVP the view is in charge.
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....
Nothing to add, just wanted to say thanks for the clarification 👏
Nice video, thanks for it.
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.
I don't understand the difference between the MVC and the MVP. They seem identical...?
That’s because they basically are the same. The downside of mvc (which according to the video is a bloated controller) is exactly the same for the second pattern. It just gets concealed by using a lot of cloudy words.
The difference is that in MVC, the View gets data from the model whereas in MVP the view gets data from the presenter. This allows the View to be even simpler and free of logic. The classic example is where the model is a temperature and you want high temperatures to be displayed in one way and low temperatures to be displayed in another. The model just delivers a number to the presenter, and the presenter makes the determination of whether the number is high or not, so it delivers the number along with a boolean to the view and the view uses the boolean to decide how to use the number. Suppose there are two views, one displays the number with say a red or blue background, the other either makes a sound or doesn’t. With MVC, both views would have to make the same decision about whether the temperature is high or the logic would have to be put in the model, even though it arguably not really “business logic”, but rather presentation logic. A more realistic example might be an text editor. Presentation state such as the current cursor position or selection will complicate the view, but probably doesn’t belong in the model. You could put it in the controller, but now your view needs to get information from two places.
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 😁
You're mixing different layers of abstraction.
I'm actually not. He commented on two-way data binding at 3:10, but glossed over it although it's a key distinction between Angular and ReactJS that you'd be acutely aware of if you've used them
@@SDFC Yes but frontend's patterns (MVC/MVVM/etc) are bound within the confines of the browser activity. The MVC pattern holistically can be approached either on the server layer, or the front end layer or even the application as a whole (remember them "n-tier applications" of yore?). That being said, certain patterns cannot be - or shouldn't be used on the pure "backend" side, esp. if your backend side is a disparate different team/server-cluster. But as was already stated in the video, it's a matter of expertise and complexity. E.g. the project we are working now on my team has around, oh, 200 microservices, 2 different main client approaches (web/mobile), not to mention the internal infrastructural anchor points, all built across a consortium of some companies/dev-teams. A pure "MVP" or "MVVM" approach cannot be "fathomed" because simply.... it can't. The scope is too big.
@@SDFC You have probably seen attributes like `value` and `setValue` passed to the component in React. It is the equivalent of two-way binding
@@gooseob No, that's actually explicitly demonstrating one-way data-binding.
In two-way data-binding, you don't need "setValue" because the attribute named "value" is directly accessible for bi-directional reads -- _and writes_
Two-way data-binding behaves similarly to an instance variable marked as "public" in java.
One-way data-binding is similar to adding a "setter" to wrap write access to an instance variable, and read access through ReactJS "props" is a bit reminiscent of constructor-based dependency injection for setting a private variable.
This is actually _advantageous_ over two-way data binding because it's more conducive to the functional paradigm, via a clear point for extracting out business logic for input validation (which is similarly a common thing done in those "setter" functions in java) or translating the input into changes in other surrounding components.
Here's a few links that may help with this, but it's explicitly stated that one-way data-binding is being used in the official ReactJS documentation and most things you'd find through a simple google search:
- stackoverflow.com/questions/42217579/data-binding-in-react
- softwareengineering.stackexchange.com/questions/419340/react-one-way-data-binding-vs-angular-two-way-data-binding
- react.dev/learn/thinking-in-react
The ReactJS creators like Dan Abramov are functional paradigm fanatics, btw. There's lots of great conference presentations and blog posts by them on the philosophy, rationale, and inspiration for a lot of the design decisions that they made, and I'd highly recommend checking it out. They're rather brilliant people, and their writings about what inspired their choices are a great means of finding content by even more brilliant people.
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.
Great video!
Would be cool if there was the MVI pattern
I would love to go over more reactive app architecture with technologies for jetpack compose or swiftui
How do you know that I've just started a project that requires this knowledge? Great timing!
Hi Sir, please also create video on ddd and clean architecture
Does anyone know what he uses for the animations?
Can u share Which tool is used to make the data flow?
Very nice
How is MVP different from MVC? I got to this part of the video and don't feel like watching the rest when I already can't understand it clearly from the examples showed
Yeah this video is trying to point out some extremely subtle differences that are sorta not real. Tbh it's all MVC. You can think of your model as a table in a database. Your view's going to be an HTML page. And your controller is going to be some back end logic PHP or Nodejs or Python or whatever you're using. Newer web frameworks (front and backend) introduce slight differences. Like react has the virtual dom so to call it purely MVC is sorta not right cause the view isn't stateless anymore, it's reactive. So it isn't waiting there for an update from the controller about some part of the model like it would be for a plain old stateless http exchange.
it's very clear, although i still don't understand it, thank you.
Looks great in the video and I understand it, but in practice I'm confused what kind of pattern I actually use when I have app with for example separate angular frontend, Java backend with REST API, with "clean" controllers used just for get/send data, services underneath doing "hard work", repositories and entities with JPA and db. Can someone tell me what pattern is that?
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?
Well, the "two-way data binding" thing from 3:10 is a legitimate difference between ReactJS and Angular
However, I have no idea what extra stuff is actually being handled by MVVM-C at 3:55 -- "react-router" is something that comes to mind, but I definitely don't recall excessive amounts of messy logic or state getting wrapped in handling that kind of behavior in any of the work that I've done 🤷♂
Hi, Any-one could you please tell me what is "Ifg" in the `typical learning curve` (At the end of the video)
This topic still confuses me a bit. I mean I kinda get it but without code, I don't actually think I understand the difference of MVC and MVP. Are you just transfering responsiblity of the frontend to the backend? Wouldn't that increase the problem of bloated controller? Also, is there any frameworks using MVVM or MVVM-C? How do we achieve this bidirectional data binding? VIPER, funny enough is very intuitive. I feel dumb after this question...
mvp always presenter is in the midle
mvc dont use presenter in the midle
XD
martin fowler have code examples
mvc is the same thing that all framework use all the times
mvp example
ProductManagmentPresent (presenter)
JFrameProductManagment (view)
ProductService(model)
ProductManagmentPresent use JFrameProductManagment (view) and
ProductService(model) and use interfaces
and use events to cordinate
@@sapito169 Using the word Service in a model class is wild.
They're all garbage patterns that over simplify things into coinable and marketable terms so people can make $ writing stupid books, ahem videos, about them. Why you would ever want your backend coupled to your frontend is beyond me. BE - here's data, FE - cool you gave me data, let me transform that into what my users want. FE - I have a new use case that would require me to hit multiple endpoints and create unnecessary load on the backend, BE - cool, I'll create a new endpoint (or GraphQL resolver) that meets your use case.
The problem w/ these "patterns" is that they try to encompass both BE & FE. VIPER makes great sense for FE, but still oversimplifies. Yes, you'll interact w/ an entity, but first you'll receive a DTO that needs to be transformed into an entity. An entity is a business object. Idk how that's ever conflated w/ a DTO. The JSON representation of an object can be vastly different than a business object. Business objects e.g. entities have behavior! Make VIPER -> VIPERD and then it's pretty accurate for FE only.
Then you have BE which is DTOs, Use cases, Models, Business logic, Actors, Serde, Services, Entities and Security. You can read all about it in my new book, "DUMBASSES: The Next Generation of Software Engineering"
MVVM was used by Oracle JET (OJET) you can find docs and tutorial about it.
very helpfull
thanks!
Great episode! Byte byte go is on its way to 💯 K subscribers, and so far bbg's YT "Shorts" have been excellent too! 😎✌️
I totally forgot that these all exist 😄 I just use nowdays everywhere Redux or something similar - because of how simple, easy to reason about and scalable it is.
Please make a video "Stack vs Heap"
I’ve seen most of these diagrams but an example with multiple screens and a list of items would be helpful
Where can I find the image that is displayed in the preview for your video?
That was really great. Such a clear overview while also giving the right amount of detail. Great job!
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.
I would argue with yes and no. Using design patterns will enable your application to be manageable and scalable. If the team is not big enough, the project development may go slower but can have the potential to grow faster when needed and you can plug in more developers.
With the exception of VIPER, the others are all basically the same 3 logical components, even if they are split differently or some part of them is moved here or there...
I am a iOS engineer now, thanks for your explanation about those pattern
You are a boss
clear as mud.
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.
Sir is clean architecture is an example of VIPER ?
All of them are MVC for me with some kind of helpers 😀
Both In MVC and MVP there is possibility of bloated controller/presenter in MVC also UI logic is isolated in view, then what's the real diff BTW MVP and MVC
Wish you had given an example for each pattern.
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.
I work in FAANG and I still have no clue what the differences are.
For some reason, explanations never seem to provide code examples. I have a feeling the borders are blurry and it’s just not a very useful distinction
@@brukts3361 I worked at faang as a FRONTEND engineer as well and these things are created to as marketing gimmicks by new frameworks. It's also part self promotion. Newbie eats it up, UA-camrs have more content and just a stupid cycle
@@brukts3361😊😊😊
@@brukts3361 I was thinking the same thing,.without a working application's code, these are all just meaningless diagrams.
I agree that it all depends on the implementation. That starts with the basic environment: Are we talking ReactWeb, iOS, Android? That choice alone might make one of the patterns built-in and some other pattern ridiculously hard to implement. The platform is the pattern. You’re just living in it.
Парень, а ты какой программой делаешь такую крутую анимацию?
Which one is NextJs
I wonder if there's an architecture pattern that allows us to start simple and then grow bigger when needed.
Yes, it's called rewrite
@@KuopassaTv that's the last thing i want to hear 😅, though I guess it's unavoidable 😞
@@MarcelinoDeseo What's the reason you don't want to hear it? Isn't it better to use a very simple approach for a proof of concept and a prototype (low number of code lines, relatively, covering only parts of the happy paths and only the main uses-cases), still a simple approach for a MVP (minimum viable product 🙂), and another when the app / system is scaled up by more features and/or user number?
@@Geza_Molnar_ I'm aware that refactoring the code is the way to go as the codebase grows, though it would be a slow and meticulous process. I was hoping for an architecture that you can use few concepts and you can just inject more with minimal effort more as the code base becomes larger.
@@MarcelinoDeseo I hope, too - However, that sounds like hoping to catch the Holly Grail :-)
If there is capacity for that, then the SOLID and other principles are a good thing to follow. The evangelists who spread the word say that those help to make refactoring an act of enjoyment and not a painful struggle. However, if there is no time for that, or at that moment the circumstances don't approve such an investment in the easiness of future development ... Then we'll burn in the hell of technical (and other) debts. At least, we are aware of that :-)
Minimal effort - for the current round of development, or for the whole long software development lifecycle, or for the sofware lifecycle? Not only managers choose the first. And not only because they don't understand software development or the expensive consequences. In an Ideal Life I'd choose the last.
How are these animations made?
so what's the difference between MVC and MVP?
I never grasp these concepts beyond surface. I never know when to implement which and just rely on iteration. For instance, recently React implemented server components, and you can literally execute backend logic inside the same code that has no only the client code but also the view/style. So if I were to follow any approach from theory(from my understanding of it) I would create way worse code than just simply seeing which patterns feel more ergonomic and maintainable.
which one is react ?
React doesn't strictly follow any architectural pattern, it's up to you to decide if you wanna use one. It is somewhat similar to MVVM though since data is binded to component state
React way with useState, is this MVVM?
Kind of yes
Why Android dev choose MVVM/MVI not VIPER?
I think it's more easier for most developer
The MVC pattern, was not born as it is today, that's important to remember.
the most wanted question is: Next js fall in which type of Architecture Patterns ?!
In all of these, which one persists the image in S3?
You're probably joking, but I'm legit curious. I would call S3 the "model" in this case, since it's the final storage medium. But I also can't tell the difference between most of these patterns, since the more complex ones seem like implementation details of slightly different MVC uses...
None of them. It's a new one called MVVMS3
@@cusemoneyman Everything is MVC at the end of the day
In the VIPER title, you misspelled Entity as Entily
Did anyone grasp anything apart from MVC?
lfg! nice way to end the video.
Alex Gem
Arrows in the diagrams are not clear, the order of what is happening is not clear except in MVC
i never heard off viper
Everyone has an architecture in mind until they get hit with the requirements.
UI developers are crazy
This seems more focused towards folder structure than code architecture, because they are the same just broken down into finer parts
What is the difference between this video and Top 5 Most Used Architecture Patterns (ua-cam.com/video/f6zXyq4VPP8/v-deo.html)? They both talk about the patterns of software creation.
Anything more than MVVM is just to gild the lily.
冒昧问一下，你认识周崇廉么？
That focuses too much on technology, and not enough on the actual architecture. Words like "view updates automatically" is just another phrasing of "the framework of my chosing updates my scaffoled application, so it looks like automation".
If you want to learn more about what MVC was supposed to mean originally, checkout Robert Martins video: "Clean Architecture".
Para mim não faz o menor sentido este monte de padrão, só gera mais confusão, deveria ter um modelo único e evolutivo, toda aplicação seja para que motivo for tende a ficar complexa.....
unfortunately they are very abstract and without code example have absolutely no use for engineers
Your biggest strengh is to cover a complicated topic within 5 to 6 mins.
But what's the difference?.😢
I've used MVC, never heard of the others and they seem pointlessly complex. So I'll not even bother.
Not really! Those other pattern such as MVVM or MVVM-C is where you see on modern framework on front-end application. If you know React, Vue whatever, they are already utilizing these architecture, and that is where you learn how those framework works from day 1
@@khoihoang8888 react is pointlessly complex lol. Its not needed 90% of the time.
Wat?
These 'patterns' do nothing except legitimise overspending of manpower on bloated projects that just don't need it. If you are a project lead considering implementing any of these, then consider that your team size is too big and you need to trim the fat
to much logic binding, prefer a more clean architecture aproach indiferent from the languaje, this only works on android.
Lets start with when the earth cooled. Nah bro, lets talk about current technology.
The framework/library you use defines the architecture of your app these days. It is good to know these patterns but no need to implement them on your own.
1st 😁
I would make choice differently
MVC - rather don’t use
MVP - delegation or closure based
MVVM - data binding approach rxswift, combine, @published
VIPER same as MVVM but you need local cache and persistent layer or have complex business logic, more complex than just network services to call web api endpoints
Generally use MVVM, name it MVVM and if needed add interactor layer and core data.
But there is also redux style TCA or ELM like action reducers architectures. They i rather cumbersome and I recommand to not use them
The so-called design pattern is not a creature by human but the way God make the world.
VIPER is the 💩
It seems like you don't understand what you speak about.
i cannot for the life on me perceive a difference between presenter and controller. mvvm, viper and clean architecture make the stupidest, slowest, jankiest most unstable applications ever. i think they were invented only to sell more development hours
Without code example it is not useful at all, it looks like some pseudo consultant IT bs slide deck
They're getting irrelevant
VIPER technically BLOC. Viper should be the goto irrespective of the app size
No