天啊!! 這東西好複雜，看了好久才知道他在說什麼。
一般來說store.dispatch應該只吃Action1 type，但是透過middleware可以包裝此dispatch變成可以吃Thunk這個型態，此型態的定義在 這裡2 ，簡單講就是一個
function(dispatch, getState)
這種型態的function。透過closure的方式，可以讓在async的地方去call這兩個redux會用到的function，來達到ajax complete的時候，去sync的呼叫dispatch來通知complete。
這個可能對於用redux的人可能會知其然但不知所以然吧，如果沒有搞懂thunk的機制，可能覺得莫名其妙吧。我同意你說的，這些abstraction不太必要，只是讓一且覺得很神奇而已，對於新手入門門檻太高了。
side effect就是改變外面的狀態就是side effect，例如counter++就是side effect。所以以下的increase function就是有side-effect
var myObject = {
counter: 0,
increase: function() {
this.counter++;
}
}
因為他改變了counter的值了。而no side-effect的版本是
function addOne(counter) {
return counter + 1;
}
state = reducer(state);
所以這個assignment是做redux裡面，而非reducer。
事實上在functional language中，assignment is evil XD。所以他們才那麼不同意Imperative programming style。
一個page出來的時候應該有initial state，不管是page init state還是server side render的init state。
而每個event都可以改變狀態。例如click event, input event, 甚至ajax complete的event，都可以當做一個讓狀態改變的action。但是reducer只專注於input跟中間的參數，跟應該有的output。
以ajax read more的例子來說。先是ajax request到server，complete的時候增加一個append的action去reduce舊狀態(只有第一頁)到新狀態(增加ajax load的新文章)，再呼叫react去render。
所以還是可以保持render跟reduce都是pure的。
好強!
看起來不只是dns route，畢竟你的link中的示意圖已經是給一個IP了，而不是domain name，感覺是同一個static global IP但是在ip routing動手腳 ( Global Fowarding Rule1 ) 。跟用DNS去做GEO去吐不同的IP不太一樣耶。
Materialized View似乎沒有那麼美好耶，會有performance impact
New in Cassandra 3.0: Materialized Views1
Materialized views do not have the same write performance characteristics that normal table writes have. The materialized view requires an additional read-before-write, as well as data consistency checks on each replica before creating the view updates. These additions overhead, and may change the latency of writes.
我對文章中另一篇 Lambda parameter names with reflection1 更有興趣，可以用來簡單定義Literal Map，可惜這要搭配特殊的compile參數。話說Java啥時才會支援Language Level Json Literal，以及Map, List, multiline literal的Support
其實MongoDB剛出來的時候有幾點有吸引到我
- Schemaless: 不得不說有些應用用這個很好用。例如你的資料來源本身就是json，並且可能偶而會在來源端修改Schema。例如，Facebook Feed。在之後分析的時候，可以透過特殊的Query語法來達到in json document的query。而且可以針對Document裡面的一個path去做index，甚至可以對array做index，這點那時候的確讓我驚艷。
- Sharding: RDBMS這個真的不容易做的好，因為需要Join。而且要怎麼設定Partition key本身就不易。所以NoSQL在這邊比較容易做得好。
但是我覺得最令我詬病的是
- Query很難用。永遠背不起來的query語法。而且用json格式真的很難寫。Aggregation pipeline跟sql group by比起來真的難寫爆多的。更何況無法做類似subquery跟join。
- 部署困難。如果資料量大到需要Sharding，部署成本難超多。若是要再加上replica set。那更是超難運作。我相信沒有幾個人會想這樣部署。
所以MongoDB對我來想，目前最好的地位是分析資料庫。也就是你可以把一堆的JSON資料塞進去，然後在裡面去做你想要的AdHoc Query。所以對於分析統計semi-structured的資料我想是目前最適合他的角色。但是PostgreSQL9.4出了以後jsonb，又有json的query好處，又可以做傳統的table join，那真的是又比MongoDB更實用，重點是有SQL。
如果往上看收集raw log的需求，MongoDB還是Row-based DB。這種型態的DB就是CRUD都是對同樣一個地方去做存取。就會遇到Data Fragmentation的問題，所以資料量一大，一定會遇到越來越慢。雖然可以透過定時去rebuild database。但是跟cassandra/hbase這種bigtable-like的還是不能比。所以真的有更大資料量的需求，我建議直上cassandra/hbase。或是更極端的用HDFS或是雲端Storage(首推AWS S3, Azure BlobStorage，因為這些Hadoop有內建FileSystem)。
Anyway，MongoDB 3.0雖然改善了很多Storage的效能問題。但是本質上的問題沒有解決，那就是沒有SQL，沒有Reliational的功能，再來是Row-based的本質跟RDBMS差距不大。但在RDBMS越做越強，主流DB都開始支援JSON的情況下，那他的特色就不是特色了。反而是他沒有的反而是他的負面特色。