一點小遺憾
對於 Notadd 我們本來期望它實現更多…
儘管我們也嘗試做了很多努力，但是由於 PHP 本身的侷限，以及考慮到開發環境配置的複雜程度，最終使用了折中方案。
接下來，我們談談整個技術選型歷程，也供今後相關開發者做借鑑和參考：
起因
我們期望 Notadd 不僅能應用到 web 領域，在嵌入式開發領域也能有所應用，同時能夠使用常用的 websocket 協議。
Swoole
swoole 是我們考慮的首選方案，但從擴充套件性來說，難以符合我們模組化的要求，對 HTTPS 和 HTTP2 支援不夠完善，同時，安裝上也難倒一些 phper。在 ARM 板的安裝過於複雜。當然也有好的一點，2.0 的自動非同步對併發量有不少提升。
workerman
主要問題還在於 workerman 對 HTTP2 等協議支援不夠完善，同時 phpsocket.io 只支援服務端模式執行，MQTT 協議也沒有相應的實現，而且以 ThinkPHP 開發者居多，成本較高。
AmPHP
amphp 有著最全的協議支援，同時有各種非阻塞擴充，可以說是最符合要求的，但是非同步需要對 laravel 做很大的改動。
ReactPHP
ReactPHP 實現上足夠優雅，但問題也足夠多，並且 PHP-cli 本身報錯機制不完善，給除錯帶來了很大困難。
PHP-PM
按照官方說明，幾乎不需要大的修改，就能將 PHP 的併發量提升 10 倍。但是在測試過程中，無法正常執行 Laravel ,所以也只能放棄～
1.0 後續的計劃
1.0 還將是 PHP 版本，並且也會有後續的更新，但會取消一些過於激進的更新，目前來說，Notadd 的門檻已經足夠高。
在上線應用商店後，也將會提供 1.0 （ PHP ） 的安裝包。包括之前一些比較激進的改動，也會根據開發者投票進行取捨。
當然，商城等模組依然會提供。
2.0 的計劃
Notadd 2.0 將基於 Nodejs 開發，同時也提供一些 1.0 無法提供的功能和特性。
為什麼是 nodeJS?
- 效能： 在 IO 密集型運算中，由於非同步非阻塞機制，NodeJS 可以輕鬆實現單機 5W 併發，而 Laravel 只有 200。
- 方便：NodeJS 可以很方便地安裝擴充，而 PHP 需要 pecl 或者 phpize 甚至重新編譯，這對很多就不怎麼熟悉環境部署的 PHPer 來說簡直就是噩夢。
- 簡單： 在 ARM 環境下只需要 Node 就夠了，不再需要 Nginx 或者 Apache，而 PHP 內建的伺服器只適合用於除錯。
- 擴充：NodeJS 本身提供了很多針對於系統層的操作，另外，npmjs.org 上也有足夠多的包來使用，這對後期的擴充來說，無疑方便了很多。
為什麼是 nest.js ?
不論是 express ThinkJS KOA EGG 都無法單一滿足於中大型專案的開發，目錄結構也會極其複雜，而借鑑 spring 思想的 nest.js 來說無疑是最適合的，並且方便 Laravel 開發者過渡。nest 預設使用 typescript ～
為什麼不直接用 Go 或者 JAVA?
說到底是開發成本原因，並且這些語言在 IO 密集型優勢並不明顯，只有 10-20% 差異，但是在開發效率上就差了很多，而且對於企業，招人也是問題。