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

2019年10月1日 171次阅读 来源: 题叶

两篇文章

今天看了两篇文章, 我觉得对我的影响会很大, 当然, 都是 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

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 还不错, 可是不适合编程, 灵活度低, 不能做太多事情

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

那么作者想, 如果反过来, 把数据库同步机制作为数据库设计的核心, 能够改善?
数据库内部通过 Logical log 的形式, 将所有的数据保存下来, 作为同步的手法
这里说的是 Apache Kafka, 我似乎记得 MongoDB, Redux, Docker, Nix 都有类似的做法
这里的 Log 有点像 Flux 当中的 Action, 随着时间就形成了 Stream, 用于同步数据

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

作者后来更加延伸一步, 觉得从数据库到屏幕像素, 整个都是数据同步的一个过程
比如说数据库的一些查询结果, 相当于 Tables 的 Materialized views, 这样一层抽象
那么, 缓存, HTML DOM, 界面像素, 其实就是后面紧跟的一层层抽象
编写应用而言, 如果整个是 Reactive 的, 后面跟着前面自动更新, 那将是非常高效的
考虑一下, HTML 是后端渲染的, 如果数据库更新了, HTML 自动局部更新多好

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

这样就需要引入 Stream 的机制了. 只不过, 前端的实现通常是发布/订阅模式
现在的 Meteor 是个特别知名的例子. Meteor 用 MongoDB 的同步机制的话可能还更像

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

这篇文章指出类似的方案已经有很多人在贡献, 在开发新的工具来实现了
而特别让我在意的是, 整套思路至少在验证我用 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 都有各自的程序和语言来抽象
在前端, 所有东西突然聚在了一起, 催生出特别多原来没有的做法, 也面临各种问题

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

Flux 对问题做了一些纠正, 避免了状态分散在 View 当中的状况, 跟 MVC 更加贴近
然而其中一些 Part 的用法, 依然存在着问题:

  1. 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
  2. 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
  3. 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 当中:

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

实际上最终作者得到的就是一个跟 Elm 类似的, State 全部集中的几个方案
同时, 所有的操作也可以被收集, 跟 Elm 一样, 可以用于重演和调试
这里的 Action 跟上面文章说的 Logical log 在思路上也非常相似
也不多说什么, 我总体上认为这是整个 React 社区未来的方向了

Big Picture

梳理一下 Time Travelling Debugger 开发的历程, 挺让人感概
早在函数式编程理论方面的研究我不熟悉就展开了
但实际上函数式编程, 不可变数据, 几乎是这一套方案得以实行的基础
因为有了统一的 State, 才能够用一个调试工具重演整个状态
而这些工具的进展, 我印象比较深的有这样一些时间点:

好多年了 Bret Victor 展示的方法, 我们日常的开发当中还没用上
好在主体的功能, 随着 React 社区两年来各种事情, 好像也就一步之遥了…

    原文作者：题叶
    原文地址: https://segmentfault.com/a/1190000003052202
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞