我覺得，光要做好 CRUD 就很不容易了耶，我想簡單談談 R 就好。
我們假設一下。
當你的 API response time 越來越高時，怎麼辦呢？
第一步可以先看看演算法和 db 有沒有調效的空間，演算法和 db 的調效就可以研究好一
段時間了。
如果調完了，還是不夠快呢？
那可以考慮分析一下你的資料，分出常變動和不常變動的，常變動的放在 db 沒問題，不
常變動可以考慮用 cache 來解決。
cache 可以考慮自已處理，或者找找適合的工具，然後要 cache 在本機還是弄個
memory 的 nosql db 呢？db 的話要 redis 或 memcached呢？
cahce 也是個可以好好研究的東西，比方說 cache 要設多長呢？設短了查詢頻率還是很
高，設長了花較多的空間，然後資料有更新是要主動去更新 cache ，還是等 cache 時間
到了下次被 hit 再更新就好？
接著我們假設一下，你已經處理好你的 cache，也榨乾你那台 server 的效能了。
接下來要嘛升級要嘛加機器，升級總會到個物理極限就不談了，談談加機器吧。
加機器那問題就又來啦。（來不完乾）
如果你是三台、五台還好，一百台你總不可能要 client 接你 100 台機器吧，那就要瞭
解一下 load balancing 啦，lb 怎麼做和怎麼做好也是一門學問。
然後 100 台機器時，你總不會還要一台一台手動去更新程式吧，那怎麼自動部署呢，比
如用用 ansible 之類啊，也是可以研究的。
然後通常也不用到 100 台機器啦，瓶頸就又會變到你的 db 那了，那這時候要怎麼解呢
？可能可以做個讀寫分流啊，怎麼做跟怎麼做好也是可以好好研究。
光 R 感覺就講不完了，量一直衝上去挑戰就會一直來，頸瓶有可能出現在你系統任何地
方，你能承受越高的挑戰你的價值自然也越高。
學無止盡，回頭是岸。
不對，是加油，共勉之 ^^