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

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