[FOOD FOR THOUGHT] interesting architecture pattern
-
There is this article:
https://www.infoq.com/articles/no-more-mvc-frameworks/
I find it a good read and can recommend not for blindly following but rather as a “mind expansion” ha ha
-
Well, he lost me, where he shoots down GraphQL and why. It’s not just Facebook using it profusely now. I’ll give him the benefit of the doubt that he wouldn’t have known how well it would be accepted and how useful it is, since the article was written right about the time when GraphQL came out in 2016.
Scott
-
@s-molinari
Yep, he opposes querying backend data from client side in larger projects.
It is his opinion of course and our chance to disagree.I posted this link, because it is another look at “reactivity” as a whole paradigm. Nice read for people used to think in terms of jquery/events.
Frankly, I’m not too fond of GraphQL either. I always assumed, that the client side technology, Vue, VueX, Quasar(?) etc. will go more in the way of this:
https://pouchdb.com/ -
Pouch is just a data storage solution. I don’t think it has much to do with business logic and indirectly business logic state or view presentation or communication of the view to the backend, etc. So, not a real solution from a holistic standpoint.
The issue with reactivity as a “whole paradigm” is the stateless nature of HTTP. Sure, you can get around that with possibly HTTP2, web sockets, etc. Even GraphQL has a pub/sub system. But in the end, a fully reactive system would be overkill for any kind of web app. It’s just not necessary. Not even for games. Some logic needs to be in the presentation layer. Some logic needs to be in a data storage layer and some logic needs to be in a business layer. These different layers can’t all be reactive or rather shouldn’t be. You’d have compute power wasted on “waiting”. And, you’d have the scenario wide open to flooding. That’s just my point of view. I might be wrong.
Scott
-
@s-molinari definitely it was a good food. About stateless he proposes to reverse the mvc and just pass the state with control, which in my opinion works superb, I used that.
You took that reactivity to another level, wow - whole reactive system, not only visuals. I agree it would be an overkill. In context of Quasar, I’d like to think of specific use cases, where such architecture level decision would be necessary. As for now, I found something like this:
Imagine QTree, where underlying hierarchical data model is lazy loaded. Changes are synchronized with backend in real-time allowing collaboration (as in google docs), with multi selection and multi cursors. And of course this data model and QTree themself allows to work offline (mobile) and supports non hierarchical data model actions (drag-n-drop and copy-paste of subtrees). Ideally data model would support peer-to-peer synchronization. Oh, sweet dreams…
