SubmissionPublisher 好像是唯一的實作的樣子。這 Flow API 看起來好像是個空殼，進入 JDK 的意義何在？
少一個 dependency 是很好，但是只用 Flow API 寫不出 app 吧，最後還不是要 depend RxJava ?
這類工具有利有弊，久了之後還是會覺得自己寫維護的問題少很多。
code gen 這類的工具，原則上只有跨平台的需求時我才會考慮 (iOS/web... 不同 client 都要用) 。不然的話我大部份傾向不使用，靠 IDE gen
value object 出了之後大概什麼都一併解決了吧。用了 VO 之後大家就不會再那邊產生一堆 getter method，而 equals/hash 也都不用寫。
我希望 JDK 10 有 union type, 一併解決 String? 這類的問題
Java 早該要原生支援 property ，不曉得在龜什麼。這又沒有很難作，其他語言都有很成熟的解法可以參考了。
原生不支援，就是一堆 code gen 的工具要煩惱
沒有 null 挺煩的，一堆 type 都會變成：
Observable<Optional<String>> o = ....
不是說禁止 null 的概念不好，是 Java 沒有 null 相關的 type 像是 String? 。 到處都加 Optional 這樣整個程式碼都會是一堆贅字。也許搭配 kotlin 用會比較合適
RouterFunction<?> route = route(GET("/person/{id}"),
request -> {
//...
return Response.ok().body(fromPublisher(person, Person.class));
})
.and(route(GET("/person"),
request -> {
//...
return Response.ok().body(fromPublisher(people, Person.class));
}))
.and(route(POST("/person"),
request -> {
//....
return Response.ok().build(repository.savePerson(person));
}));
三個 route 還好，等到變成 20 個以上就會哭了。而且 IDE 看不到 method 的定義，也幫不了你。 Java 還沒有到能完全套用 functional 的 style...
文中指出五大迷思：
- microservices 引導更簡潔的程式碼
but: “You don’t need to introduce a network boundary as an excuse to write better code.”
- microservices 架構下更好實作
but: “Distributed transactions are never easy.”
- microservices 更快
but: “You could gain a lot of performance in a monolith by simply applying a little extra discipline.”
- microservices 對工程師簡單
but: “A bunch of engineers working in isolated codebases leads to ‘Not my problem’ syndrome.”
- microservices scale 更好
but: “You can scale a microservice outward just as easily as you can scale a monolith.”
----
microservice 的 boundary 應該是沿用原本組織的部門去區分才是 (大方向…)，而不是上述的一些錯誤理由。
是說沒有在寫 Rust，不過這類 Trait 取代繼承的問題在不少語言都會遇到 (Java8 的 Default method 也算)，遇到了就是得重新設計架構了。原作者想要移植一個 OOP 的 Widget 到 Rust，照搬的話一定會撞牆…