对于 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% 差异，但是在开发效率上就差了很多，而且对于企业，招人也是问题。