您现在的位置是:首页 > 文章详情

关于数据库, 关于 MVC, 也关于 React的两篇文章读后感


【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》


今天看了两篇文章, 我觉得对我的影响会很大, 当然, 都是 React 相关的:

一篇是 Martin Kleppmann 在 Strangeloop 2014 大会上的演讲, 有视频, 也有文字版, 关于数据库:

Turning the database inside-out with Apache Samza


另一篇是 Christian Alfoni 关于 Flux 的文章, 从 Twitter 上看到的, 关于 MVC 架构:

Why we are doing MVC and FLUX wrong





前面一篇是在 Redux 的文档上看到的, 这文档上有不少我关心的技术:


  • 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 当中:

  • 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 一样, 可以用于重演和调试

这里的 Action 跟上面文章说的 Logical log 在思路上也非常相似

也不多说什么, 我总体上认为这是整个 React 社区未来的方向了

Big Picture

梳理一下 Time Travelling Debugger 开发的历程, 挺让人感概


但实际上函数式编程, 不可变数据, 几乎是这一套方案得以实行的基础

因为有了统一的 State, 才能够用一个调试工具重演整个状态

而这些工具的进展, 我印象比较深的有这样一些时间点:

2012年2月, Bret Victor 发表了演讲 Inventing on Principle, 此后一再被引用


同样是2月, Chris Granger 开始连载关于 Light Table 调试功能的一些文档


2014 年 5 月或者早一些, Elm 发布了关于 Time Travelling Debugger 的文章


5月的 WWDC, Swift 语言发布 Playground, 集成了部分 LightTable 当中的调试功能


7月初, 基于 Webpack 的代码热替换开始在社区传播, 也是后来 Redux 的作者


2015年4月底 Bruce Hauman 在 Clojure Eroupe 上发布 Figwheel 类似的时间调试功能


6月初 React Eroupe 上 Redux 发布, 开始做 React 的 Time Travelling Debugger


刚才的这个 Cerebral, 大概上个月的事情, 也是基于 React 类似的功能


好多年了 Bret Victor 展示的方法, 我们日常的开发当中还没用上

好在主体的功能, 随着 React 社区两年来各种事情, 好像也就一步之遥了...

【责任编辑: chenqingxiang TEL:(010)68476606】