關于數據庫, 關于 MVC, 也關于 React的兩篇文章讀后感

2015-08-17 09:59:49

今天看了兩篇文章, 我覺得對我的影響會很大, 當然, 都是 React 相關的:一篇是 Martin Kleppmann 在 Strangeloop 2014 大會上的演講, 有視頻, 也有文字版, 關于數據庫:另一篇是 Christian Alfoni 關于 Flux 的文章, 從 Twitter 上看到的, 關于 MVC 架構:

[[145451]]

兩篇文章

今天看了兩篇文章, 我覺得對我的影響會很大, 當然, 都是 React 相關的:

一篇是 Martin Kleppmann 在 Strangeloop 2014 大會上的演講, 有視頻, 也有文字版, 關于數據庫:

Turning the database inside-out with Apache Samza

http://www.confluent.io/blog/turning-the-database-inside-out-with-apac...

另一篇是 Christian Alfoni 關于 Flux 的文章, 從 Twitter 上看到的, 關于 MVC 架構:

Why we are doing MVC and FLUX wrong

http://www.christianalfoni.com/articles/2015_08_02_Why-we-are-doing-MV...

https://www.youtube.com/watch?v=xCIv4-Q2dtA

http://www.christianalfoni.com/todomvc/#/

來源

前面一篇是在 Redux 的文檔上看到的, 這文檔上有不少我關心的技術:

http://gaearon.github.io/redux/index.html

The Elm Architecture a great intro to modeling state updates with reducers;
Turning the database inside-out for blowing my mind;
Developing ClojureScript with Figwheel for convincing me that re-evaluation should "just work"
Webpack for Hot Module Replacement;
Flummox for teaching me to approach Flux without boilerplate or singletons;
disto for a proof of concept of hot reloadable Stores;
NuclearJS for proving this architecture can be performant;
Om for popularizing the idea of a single state atom;
Cycle for showing how often a function is the best tool;
React for the pragmatic innovation.

Redux 的作者最近在 Twitter 上非常活躍, 總是在發各種 Redux 相關的消息

我的感覺是 Redux 一出來, React 社區跟函數式編程, 跟未來, 的距離又拉進了一步, 一大步

包括 Clojure, Elm, PureScript 在 Twitter 上也非常地活躍... 當然也因為我關注多了這些人

然后我就常常在想, 函數式編程是真的在復興了對吧, 到處都出現了?

關于數據庫

***篇文章很難懂, 還好圖片多, 大致的意思就是重新思考一下數據庫

常用的數據庫都在基于上世紀的硬件條件設計的, 受到各種限制

如果我們重新思考一下數據庫的應用, 應該怎么考慮設計新的方案?

然后作者梳理了一下數據庫應用當中的幾個重要的點:

Replication 數據庫同步

Secondary indexing 輔助索引

Cache 緩存

Materialized views 物化視圖

We first discussed replication, i.e. keeping a copy of the same data on multiple machines. It generally works very well, so we’ll give it a green smiley. There are some operational quirks with some databases, and some of the tooling is a bit weird, but on the whole it’s mature, well-understood, and well-supported.
Similarly, secondary indexing works very well. You can build a secondary index concurrently with processing write queries, and the database somehow manages to do this in a transactionally consistent way.
On the other hand, application-level caching is a complete mess. Red frowny face.
And materialized views are so-so: the idea is good, but the way they’re implemented is not what you’d want from a modern application development platform. Maintaining the materialized view puts additional load on the database, while actually the whole point of a cache is to reduce load on the database!

實際開發的感受而言, 前兩者在數據庫內部實現很高效, 也不需要太多操心

Cache 相對來說就是一團亂麻的實現, 非常難管理

Materialized views 還不錯, 可是不適合編程, 靈活度低, 不能做太多事情

那么作者想, 如果反過來, 把數據庫同步機制作為數據庫設計的核心, 能夠改善?

數據庫內部通過 Logical log 的形式, 將所有的數據保存下來, 作為同步的手法

這里說的是 Apache Kafka, 我似乎記得 MongoDB, Redux, Docker, Nix 都有類似的做法

這里的 Log 有點像 Flux 當中的 Action, 隨著時間就形成了 Stream, 用于同步數據

作者后來更加延伸一步, 覺得從數據庫到屏幕像素, 整個都是數據同步的一個過程

比如說數據庫的一些查詢結果, 相當于 Tables 的 Materialized views, 這樣一層抽象

那么, 緩存, HTML DOM, 界面像素, 其實就是后面緊跟的一層層抽象

編寫應用而言, 如果整個是 Reactive 的, 后面跟著前面自動更新, 那將是非常高效的

考慮一下, HTML 是后端渲染的, 如果數據庫更新了, HTML 自動局部更新多好

這樣就需要引入 Stream 的機制了. 只不過, 前端的實現通常是發布/訂閱模式

現在的 Meteor 是個特別知名的例子. Meteor 用 MongoDB 的同步機制的話可能還更像

這篇文章指出類似的方案已經有很多人在貢獻, 在開發新的工具來實現了

而特別讓我在意的是, 整套思路至少在驗證我用 Cumulo 探索的方案至少出發點很不錯

實際上 Datomic, Redux 這些我在關注的技術, 也是朝著類似的方向前進的

有不小的可能, 未來我們開發應用的方式, 整體是就是依照這套辦法做下去

關于 MVC

另一篇文章是在講 MVC 和 Flux 的問題, ***拋出自己基于 React 寫的 Cerebral

從文章的章節標題可以看到具體的脈絡,

MVC 在前端遇到什么問題, Flux 怎么改進, 還能怎么改進:

Traditional MVC
Application state
State in traditional MVC
When we moved to the frontend
The router is not a controller
The view layer bypassed the controller layer
No concept of a single state store
State in the view layer
What FLUX improved
Fixing the problem
A single state store
A controller with middleware
The views talk to the controller
Just do the routing
So what benefits do I really get?
Summary

后端而言, 各個 Part 之間隔離非常明顯, MVC 都有各自的程序和語言來抽象

在前端, 所有東西突然聚在了一起, 催生出特別多原來沒有的做法, 也面臨各種問題

Multiple views
State also inside views
Multiple models
We bypass the view controller model flow
The router is no longer the only entry point for state change

Flux 對問題做了一些糾正, 避免了狀態分散在 View 當中的狀況, 跟 MVC 更加貼近

然而其中一些 Part 的用法, 依然存在著問題:

The FLUX architecture uses multiple models (stores). With traditional MVC you only have one model, your database. Multiple stores quickly causes problems when a dispatch needs to reach more than one store and especially if one store needs to know about state in an other
There is no concept of middleware like in a traditional controller. This quickly introduced the concept of action creators. They are much like a single middleware that is responsible for doing everything needed related to a request from the view layer, often doing multiple dispatches to the stores
When the view layer wants to get some state they still do it directly from the model layer, making unnecessary complex dependencies in the views

作者也提出了具體的解決方案, 最主要的是數據和狀態要統一到 Model 當中: