My thoughts after reading two articles about database, MVC and React

[[145451]]

Two articles

I read two articles today, which I think will have a great impact on me. Of course, they are all React related:

One is Martin Kleppmann's speech at the Strangeloop 2014 conference, with both video and text, about databases:

Turning the database inside-out with Apache Samza

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

Another article is Christian Alfoni's article about Flux, which I saw on Twitter, about the MVC architecture:

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/#/

source

The previous article was seen in the Redux documentation, which contains a lot of technologies I care about:

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.

The author of Redux has been very active on Twitter recently, always posting various Redux-related messages

I feel that once Redux came out, the React community took a big step closer to functional programming and the future.

Clojure, Elm, PureScript are also very active on Twitter... Of course, it's also because I follow more of them

Then I often wondered, functional programming is really having a resurgence, right? It's appearing everywhere?

About Database

***The article is hard to understand, but fortunately there are many pictures. The general idea is to rethink the database.

Commonly used databases are designed based on the hardware conditions of the last century and are subject to various restrictions.

If we rethink the application of database, how should we consider designing new solutions?

Then the author sorted out several important points in database applications:

Replication Database Synchronization

Secondary indexing

Cache

Materialized views

• We first discussed replication, ie 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!

In terms of actual development experience, the first two are very efficient in the database and do not require much worry.

Cache is a relatively messy implementation and very difficult to manage

Materialized views are good, but not suitable for programming, low flexibility, and can't do much

So the author wonders, if we take the database synchronization mechanism as the core of database design, can it be improved?

The database saves all data in the form of Logical log as a synchronization method.

This is about Apache Kafka. I seem to remember that MongoDB, Redux, Docker, and Nix all have similar practices.

The Log here is a bit like the Action in Flux. Over time, it forms a Stream, which is used to synchronize data.

The author later went a step further and thought that the entire process from database to screen pixels is a process of data synchronization.

For example, some query results of the database are equivalent to Materialized views of Tables, such a layer of abstraction

So, cache, HTML DOM, interface pixels, are actually layers of abstraction that follow closely behind.

When writing applications, it would be very efficient if the entire application is reactive and the following updates are automatically followed by the previous ones.

Consider that HTML is rendered by the backend. If the database is updated, it would be great if the HTML is automatically partially updated.

In this case, we need to introduce the Stream mechanism. However, the front-end implementation is usually a publish/subscribe model.

Meteor is a particularly well-known example. If Meteor uses MongoDB's synchronization mechanism, it may be more like

This article points out that many people have contributed to similar solutions and developed new tools to achieve this.

What particularly interests me is that the whole idea at least verifies that the solution I explored with Cumulo is at least a good starting point.

In fact, the technologies I am paying attention to, such as Datomic and Redux, are also moving in a similar direction.

There is a high possibility that the way we develop applications in the future will be based on this approach.

About MVC

Another article is about the problem of MVC and Flux, and I will introduce Cerebral, which is based on React.

The specific context can be seen from the chapter titles of the article.

What problems does MVC encounter on the front end, how can Flux improve it, and how can it be improved:

• 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

In terms of the backend, the isolation between the various parts is very clear, and MVC has its own program and language to abstract

On the front end, everything suddenly came together, giving rise to a lot of practices that didn’t exist before, and also facing various problems

• 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 makes some corrections to the problem, avoiding the situation where the state is scattered in the View, and is closer to MVC

However, there are still some problems with the usage of some Parts:

• 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

The author also proposed a specific solution, the most important of which is that data and status should be unified into the 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

In fact, what the author finally got was a solution similar to Elm, where all states are centralized.

At the same time, all operations can also be collected, just like Elm, which can be used for replay and debugging

The Action here is very similar to the Logical log mentioned in the above article in terms of idea.

Without saying much, I generally think this is the future direction of the entire React community.

Big Picture

Looking back at the development process of Time Travelling Debugger, it is quite touching

I started my research on functional programming theory long before I was familiar with it.

But in fact, functional programming and immutable data are almost the basis for the implementation of this solution.

Because of the unified State, the entire state can be replayed with a debugging tool

As for the progress of these tools, I was particularly impressed by the following time points:

In February 2012, Bret Victor gave a speech called Inventing on Principle, which has been cited repeatedly since then.

https://www.youtube.com/watch?v=PUv66718DII

Also in February, Chris Granger started serializing some documentation about Light Table debugging features

http://www.chris-granger.com/2012/02/26/connecting-to-your-creation/

In May 2014 or earlier, Elm published an article about Time Travelling Debugger

http://wadler.blogspot.sg/2014/05/elms-time-travelling-debugger.html

At WWDC in May, Swift released Playground, which integrates some debugging functions of LightTable.

https://www.youtube.com/watch?v=oY6nQS3MiF8

In early July, Webpack-based code hot replacement began to spread in the community, and later the author of Redux

https://gaearon.github.io/react-hot-loader/2014/07/23/integrating-jsx-…

At the end of April 2015, Bruce Hauman released Figwheel, a similar time debugging function, on Clojure Eroupe.

https://www.youtube.com/watch?v=j-kj2qwJa_E

In early June, React Eroupe was released on Redux, and we started working on React's Time Travelling Debugger.

https://www.youtube.com/watch?v=xsSnOQynTHs

The Cerebral mentioned above was developed last month and is also based on React.

For many years, the method Bret Victor showed us has not been used in our daily development.

Fortunately, with the various things that the React community has done in the past two years, the main functions seem to be just one step away...