前面我們從開發上的細節，一路談到測試、部署，算是圓滿走完一個迴圈了，但是，這樣的 Boilerplate 其實還有很多不足之處，對我來說，它永遠都是有改進空間的，所以今天要來講的不是技術細節，而是這個專案的遠景以及未來。

React Native

首先我想做的是徹底落實 Universal 的精神，讓這一套 Codebase 不只是用在 Modern Web 的開發，而是把觸手伸往手機的 Native App，或是 Web-Based 的 PC App。React Native（簡稱 RN）是一個很有潛力的 Native App 開發工具，一樣使用 JSX 的語法，一樣使用 Redux 來管理狀態，一樣遵守 Flux 流程，一樣呼叫 Isomorphic API，基本上很多 Codebase 都是可以重複使用的。

目前我已經有試著在 Boilerplate 整合 RN，但是可能會有一些架構上的變動，所以實在不得不謹慎規劃，總之就敬請各位期待吧！

Payment Service

這個 Boilerplate 一直都是以商業考量為重心，理當要有金流服務，但是筆者實在分身乏術，還沒有時間整合金流相關的功能，目前只有參考過幾個不同的 Library 或 SDK，乍看下 Stripe 將會是我的首選，瞄過文件就略懂 7 成了，其它 Library 幾乎都是有看沒有懂，或者是對台灣的支援度不夠。日後如果整合好金流功能，可能會實作個 Donate Button 跟各位討錢吧 XD

API Versioning

第三項是關於 API 的 Issue，目前 Boilerplate 的 API Server 沒有考量過版本的劃分，筆者雖然曾經查詢過相關議題，但網路上的風向好像亂亂的，有的人習慣把版本號塞進 URL：

http://company.com/api/v3.0/customers/123

有的人覺得要塞進 HTTP Header，讓 URL 保持乾淨的 RESTful 形式：

Content-Type: application/vnd.company.myapp-v3+json

我自己是偏好塞在 Header，不過要實作 API Versioning 也要很久之後了吧...

CLI Code Generator

Boilerplate 本來就是拿來加速開發用的，所以我其實很想提供像 Rails 那樣的 CLI 工具，敲幾個指令就幾乎快把網站完成了。不過這個功能不能夠急著做，我想繼續實驗整個 Boilerplate 的架構是否有足夠的可靠度，等到整個架構不會朝令夕改的時候，才能夠發展 CLI 來自動化產生 Code。

以上四點是我目前對 Boilerplate 未來的主要想法，其餘的支線任務都列在 README 的 Roadmap 中，當然，這一切都只是我自己在腦補和幻想，隨時都可能說改就改，最終還是會看心情挑功能來實作！