You mention exactly the situation I was thinking about. The one conference talk from Googler’s about bloc lead to an Industry wide belief that it’s tge right way to do apps. Same followed when recommending provider some years later. For everyone else working in this field it’s super difficult to get heard and rely good approaches get ignored by most.
I’m not sure how to solve the contradiction to provide guidance without making people think there is only one way.
Yeah, I think probably a lot of lessons have been learned over the years here around the communication or recommendation side of things. I ironically see it in a slightly different way in that it was actually a lack of concrete guidance around this topic specifically that just ended up with what felt like the same 2-3 conversations on repeat for years now and nobody was moving forward.
The idea that they would land on essentially saying “MVVM” as a general pattern is something that works really well in building apps that isn’t overly complicated and has proven itself in a whole bunch of different contexts across time now is an entirely sensible and healthy place to land and then there is just a lot of additional “here’s how to go about implementing that in Flutter specifically” on top of that along with a lot of educational material to explain the how and why behind it all is also a really welcome addition in my opinion.
I don’t see that at all leaving out from the conversation if you want to use get_it (which I quite like by the way) for DI over provider you can do so obviously, the larger architecture doesn’t change at all. Same with if you want to do something other than change notifier for state management etc.
So in that sense, I think that actually does a good job of addressing all of the various concerns etc while still giving people an extremely concrete set of examples and documentation to work from if they don’t have any reason to want or pick something else.
However, I honestly don’t understand why they chose MVVM because I repeatedly argued that it is not a good match for Flutter which follows MVU pattern. MVVM makes sense if you have some markup UI with automatic data binding. Flutter Widgets don’t need ViewModels to bind to any data object.
But I agree, that it is really a consequence of not giving clear guidance on how to structure whole apps with the argument that Flutter is just a UI Framework.
Yeah I think at the end of the day it’s about moving beyond “flutter” specific stuff and back into the realm of building modular apps using existing OOP patterns that a good chunk of you might even know from other contexts. Which again, seems entirely sensible and anyone who’s senior enough to know when that’s not a good fit for their use case is not going to need someone else to tell them.
I think you all got there yourselves through your conversation, but I’ll comment here to make it explicit. This might also provide insight into how the team thinks about the learning resources we make.
This architecture guidance wasn’t really written for experienced app developers who are familiar with Flutter, because 1) they likely understand that there’s nuance in everything. And 2) there’s nothing in this guidance that will be unfamiliar to them. MVVM isn’t a new concept, using repositories isn’t a new concept, etc.
Big, complex apps with many developers working on the same codebase will also not likely find this guidance super helpful. They probably have unique requirements and have to adjust accordingly.
These docs we’re written for folks who are either A) new-ish developers that aren’t confident in architecting an app themselves, or B) experienced developers new to Flutter that want some kind of starting point to understand how Flutter apps are generally architected. (B is the real target audience FWIW)
In order to write these docs at all, we had to be opinionated. It’s not feasible to document every possible architecture that could be used in any given situation.
That said, I do think we made the best decisions that are most generally useful to largest number of people, and can be most easily modified to fit your needs.
I wouldn’t read too into the choices we made about packages or specific APIs in the compass_app example.
For example, If I was starting to build an app today for production use, there’d be way more streams and way less ChangeNotifiers. I simply prefer thinking in Streams, while there are many people on the team that prefer CN. Regardless, CN is the best choice to trigger UI updates for this project because we want to teach people the underlying platform and skills, not how to use a package.
It reminds me a lot of a question that folks used to ask constantly in the ReactJS world: “Should I learn React first, or focus on learning JavaScript?” The answer from any experienced developer was a resounding “learn JS first!”
Thanks so much for the context. Makes a lot of sense, much appreciated!
Hi all, nice full stack app in the opening post!
I am using also a very solid architecture in my apps, which is maybe not super in line with the current trends, however I think it should be the recommendet architecture for most apps that use more than 1 main feature. Where would be the correct thread to post this?
@feichtmeier Just create a new one under Architecture & Patterns
First part of the documentation has been published!
More to come 
I have read it today, it was an amazing read that will help the community. Thanks for the effort.
By the way, after reading this post replies, I remembered this classic repository by Brian Egan (he is not more active in the community 
):
I see the first of the cookbooks also just launched for anyone who’s interested, it’s a great read: Optimistic State | Flutter
And I just noticed that today they released two more cookbooks:
@ericwindmill I hope that you will consider a cookbook piece in the docs that does look at Streams rather than change notifier just to help reinforce the pattern but also to avoid it becoming something overly dogmatic in its current form, also just I think it would be an excellent learning resource for people too so they could compare and contrast.
I do plan on making a copy of the sample app but with Streams, which would likely lead to writing about it somewhere.
That would be genuinely amazing thank you so much for all the work you, @miquel and everyone else who was involved with making this happen, this is such a valuable resource for so many people
I’ve considered reaching out to Brian and asking if we can take over the repository, or perhaps hand it off to the Flutter Community Github. I haven’t thought about it enough to come to any conclusion.
When I was new to Flutter, I found this repository so helpful. It’d be nice to keep it maintained.
Probably would need quite some updating.
Will try to make a fork of your app and adapt to my preferred architecture
I recently came across a great resource that fits perfectly with the idea of a full-stack Dart/Flutter reference architecture. The example app is called ‘Simple CRM,’ which demonstrates a basic customer relationship management tool. It features a Dart backend and a Flutter frontend, showcasing how the two work seamlessly together.
One thing I really appreciate is how it bridges the gap between theory and practical, real-world implementation—something I struggled with early on in my Flutter App Development journey. The example covers user authentication, data persistence, and state management, making it an excellent starting point for anyone building a more complex app.
Can you add a link to that example?
It's All Widgets! • Flutter Pro • FlutterX • Flutter Streams • Flutter Podcast
Supported by Invoice Ninja - Free Invoicing Software for Small Business [ Demo | Package | Code | Apps ]
Flutter and the related logo are trademarks of Google LLC. We are not endorsed by or affiliated with Google LLC.
Using contents of this forum for the purposes of training proprietary AI models is forbidden. Only if your AI model is free & open source, go ahead and scrape.