摘要：兩篇文章今天看了兩篇文章我覺得對我的影響會很大當然都是相關(guān)的一篇是在大會上的演講有視頻也有文字版關(guān)于數(shù)據(jù)庫另一篇是關(guān)于的文章從上看到的關(guān)于架構(gòu)來源前面一篇是在的文檔上看到的這文檔上有不少我關(guān)心的技術(shù)的作者最近在上

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

一篇是 Martin Kleppmann 在 Strangeloop 2014 大會上的演講, 有視頻, 也有文字版, 關(guān)于數(shù)據(jù)庫:

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

另一篇是 Christian Alfoni 關(guān)于 Flux 的文章, 從 Twitter 上看到的, 關(guān)于 MVC 架構(gòu):

  
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 的文檔上看到的, 這文檔上有不少我關(guān)心的技術(shù):
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 上非常活躍, 總是在發(fā)各種 Redux 相關(guān)的消息
我的感覺是 Redux 一出來, React 社區(qū)跟函數(shù)式編程, 跟未來, 的距離又拉進了一步, 一大步
包括 Clojure, Elm, PureScript 在 Twitter 上也非常地活躍... 當然也因為我關(guān)注多了這些人
然后我就常常在想, 函數(shù)式編程是真的在復興了對吧, 到處都出現(xiàn)了?

第一篇文章很難懂, 還好圖片多, 大致的意思就是重新思考一下數(shù)據(jù)庫
常用的數(shù)據(jù)庫都在基于上世紀的硬件條件設計的, 受到各種限制
如果我們重新思考一下數(shù)據(jù)庫的應用, 應該怎么考慮設計新的方案?

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

Replication 數(shù)據(jù)庫同步

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!
  

實際開發(fā)的感受而言, 前兩者在數(shù)據(jù)庫內(nèi)部實現(xiàn)很高效, 也不需要太多操心
Cache 相對來說就是一團亂麻的實現(xiàn), 非常難管理
Materialized views 還不錯, 可是不適合編程, 靈活度低, 不能做太多事情

那么作者想, 如果反過來, 把數(shù)據(jù)庫同步機制作為數(shù)據(jù)庫設計的核心, 能夠改善?
數(shù)據(jù)庫內(nèi)部通過 Logical log 的形式, 將所有的數(shù)據(jù)保存下來, 作為同步的手法
這里說的是 Apache Kafka, 我似乎記得 MongoDB, Redux, Docker, Nix 都有類似的做法
這里的 Log 有點像 Flux 當中的 Action, 隨著時間就形成了 Stream, 用于同步數(shù)據(jù)

作者后來更加延伸一步, 覺得從數(shù)據(jù)庫到屏幕像素, 整個都是數(shù)據(jù)同步的一個過程
比如說數(shù)據(jù)庫的一些查詢結(jié)果, 相當于 Tables 的 Materialized views, 這樣一層抽象
那么, 緩存, HTML DOM, 界面像素, 其實就是后面緊跟的一層層抽象
編寫應用而言, 如果整個是 Reactive 的, 后面跟著前面自動更新, 那將是非常高效的
考慮一下, HTML 是后端渲染的, 如果數(shù)據(jù)庫更新了, HTML 自動局部更新多好

這樣就需要引入 Stream 的機制了. 只不過, 前端的實現(xiàn)通常是發(fā)布/訂閱模式
現(xiàn)在的 Meteor 是個特別知名的例子. Meteor 用 MongoDB 的同步機制的話可能還更像

這篇文章指出類似的方案已經(jīng)有很多人在貢獻, 在開發(fā)新的工具來實現(xiàn)了
而特別讓我在意的是, 整套思路至少在驗證我用 Cumulo 探索的方案至少出發(fā)點很不錯
實際上 Datomic, Redux 這些我在關(guān)注的技術(shù), 也是朝著類似的方向前進的
有不小的可能, 未來我們開發(fā)應用的方式, 整體是就是依照這套辦法做下去

另一篇文章是在講 MVC 和 Flux 的問題, 最后拋出自己基于 React 寫的 Cerebral
從文章的章節(jié)標題可以看到具體的脈絡,
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 對問題做了一些糾正, 避免了狀態(tài)分散在 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
  

作者也提出了具體的解決方案, 最主要的是數(shù)據(jù)和狀態(tài)要統(tǒng)一到 Model 當中:

  
We should have one model in our model layer
  
All our state should be contained inside the model layer
  
We should have one controller in our controller layer
  
The view layer can only communicate with the controller layer
  
Use a router that does not control the view layer
  

實際上最終作者得到的就是一個跟 Elm 類似的, State 全部集中的幾個方案
同時, 所有的操作也可以被收集, 跟 Elm 一樣, 可以用于重演和調(diào)試
這里的 Action 跟上面文章說的 Logical log 在思路上也非常相似
也不多說什么, 我總體上認為這是整個 React 社區(qū)未來的方向了

梳理一下 Time Travelling Debugger 開發(fā)的歷程, 挺讓人感概
早在函數(shù)式編程理論方面的研究我不熟悉就展開了
但實際上函數(shù)式編程, 不可變數(shù)據(jù), 幾乎是這一套方案得以實行的基礎
因為有了統(tǒng)一的 State, 才能夠用一個調(diào)試工具重演整個狀態(tài)
而這些工具的進展, 我印象比較深的有這樣一些時間點:

2012年2月, Bret Victor 發(fā)表了演講 Inventing on Principle, 此后一再被引用
https://www.youtube.com/watch?v=PUv66718DII

同樣是2月, Chris Granger 開始連載關(guān)于 Light Table 調(diào)試功能的一些文檔
http://www.chris-granger.com/2012/02/26/connecting-to-your-creation/

2014 年 5 月或者早一些, Elm 發(fā)布了關(guān)于 Time Travelling Debugger 的文章
http://wadler.blogspot.sg/2014/05/elms-time-travelling-debugger.html

5月的 WWDC, Swift 語言發(fā)布 Playground, 集成了部分 LightTable 當中的調(diào)試功能
https://www.youtube.com/watch?v=oY6nQS3MiF8

7月初, 基于 Webpack 的代碼熱替換開始在社區(qū)傳播, 也是后來 Redux 的作者
https://gaearon.github.io/react-hot-loader/2014/07/23/integrating-jsx-...

2015年4月底 Bruce Hauman 在 Clojure Eroupe 上發(fā)布 Figwheel 類似的時間調(diào)試功能
https://www.youtube.com/watch?v=j-kj2qwJa_E

6月初 React Eroupe 上 Redux 發(fā)布, 開始做 React 的 Time Travelling Debugger
https://www.youtube.com/watch?v=xsSnOQynTHs

剛才的這個 Cerebral, 大概上個月的事情, 也是基于 React 類似的功能
http://www.christianalfoni.com/todomvc/#/

好多年了 Bret Victor 展示的方法, 我們?nèi)粘５拈_發(fā)當中還沒用上
好在主體的功能, 隨著 React 社區(qū)兩年來各種事情, 好像也就一步之遙了...