For Notadd we would have expected it to achieve more ...
Although we tried to make a lot of efforts, we ended up using a compromise because of the limitations of PHP itself and the complexity of the development environment configuration.
Next, we talk about the entire technology selection process, but also for the future relevant developers to do reference and reference:
Cause
We expect notadd not only to be applied to the web, but also to be used in the field of embedded development and to use common websocket protocols.
Swoole
Swoole is the preferred solution for our consideration, but it is difficult to meet our modularity requirements for extensibility, and the support for HTTPS and HTTP2 is not perfect, and the installation is also stumped by some phper. The installation of the ARM board is too complex. Of course, there is a good point, 2.0 of the automatic asynchronous to the concurrency of a lot of improvements.
Workerman
The main problem is that Workerman to HTTP2 and other protocol support is not perfect, while Phpsocket.io only support service-side mode operation, the MQTT protocol does not have the corresponding implementation, and the majority of thinkphp developers, high cost.
amphp
Amphp has the most complete protocol support, but also has a variety of non-blocking expansion, it can be said that the most meet the requirements, but the asynchronous need to make great changes to Laravel.
reactphp
reactphp implementation is elegant enough, but the problem is enough, and PHP-CLI itself error mechanism is not perfect, to debugging has brought great difficulties.
php-pm
According to the official note, there is little need for big changes to increase PHP concurrency by up to 10 times times. However, during the testing process, Laravel cannot be run properly, so you can only give up ~
1.0 Follow-up plan
1.0 will also be PHP version, and there will be a follow-up update, but will remove some overly radical updates, at present, the notadd threshold is high enough.
The 1.0 (PHP) installation package will also be available after the online app store. Including some of the more radical changes, will also be based on the developer vote choice.
Of course, the mall and other modules will still be available.
2.0 of the Plan
Notadd 2.0 will be developed based on Nodejs, while providing features and features that are not available in 1.0.
Why the NodeJS?
- Performance: In IO-intensive operations, NodeJS can easily implement 5W concurrency with asynchronous non-blocking mechanisms, while Laravel is only 200.
- Convenience: NodeJS can easily install the extension, and PHP needs to pecl or phpize even recompile, which is not familiar with the environment of the deployment of Phper is simply a nightmare.
- Simple: Only Node is needed in an ARM environment, no Nginx or Apache is required, and PHP's built-in server is only suitable for debugging.
- Expansion: NodeJS itself provides a lot for the operation of the system layer, in addition, there are enough npmjs.org on the package to use, which for the later expansion, no doubt convenient a lot.
Why the Nest.js?
Whether it is the Express ThinkJS KOA EGG can not be single satisfied with the development of large and medium-sized projects, the directory structure will be extremely complex, and draw on the spring thought of nest.js is undoubtedly the most suitable, and convenient Laravel developers transition. nineth Cinema Nest default use Typescript ~
Why not use Go or JAVA directly?
In the final analysis is the development cost reasons, and these languages in IO-intensive advantage is not obvious, only 10-20% differences, but in the development efficiency is much worse, and for enterprises, hiring is also a problem.
Notadd 2.0 new node. JS version ~ (in development) [from PHP to Node's tread]