+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: CodeIgniter 4 (https://forum.codeigniter.com/forumdisplay.php?fid=28)
+--- Forum: CodeIgniter 4 Discussion (https://forum.codeigniter.com/forumdisplay.php?fid=31)
+--- Thread: Long-living PHP support (Swoole/RoadRunner etc) (/showthread.php?tid=83970)
Pages:
1
2
Long-living PHP support (Swoole/RoadRunner etc) - kenjis - 10-13-2022
I would like to support Long-living PHP like Swoole, RoadRunner, etc.
If anyone is trying to get CI4 to work with these, I would like to exchange information.
And I want to make CI4 work with these easily.
Long-living PHP is a completely different architecture than the traditional shared nothing PHP
like Apache module or PHP-FPM server. And CodeIgniter4 is not designed for it.
So I would like to improve CI4 implementation little by little to support these.
Of course, in order for CI4 apps to work with these, the application code must be written to work with them as well as the framework.
References
https://roadrunner.dev/
https://openswoole.com/
https://www.swoole.com/
https://github.com/walkor/workerman
https://github.com/monkenWu/CodeIgniter4-Burner
https://github.com/codeigniter4/CodeIgniter4/issues/6650
https://forum.codeigniter.com/showthread.php?tid=83596
https://forum.codeigniter.com/showthread.php?tid=71761
https://forum.codeigniter.com/showthread.php?tid=77009
RE: Long-living PHP support (Swoole/RoadRunner etc) - luckmoshy - 10-13-2022
of course, I think is one best impressive deals waiting...!
RE: Long-living PHP support (Swoole/RoadRunner etc) - demyr - 10-13-2022
Hi Kenjis. Can you elaborate? Are you creating something new or just new packages to help us work with them easily?
Plus, have you checked this : https://forum.codeigniter.com/showthread.php?tid=78004
They have a github which cannot be noticed easily within the post.
RE: Long-living PHP support (Swoole/RoadRunner etc) - kenjis - 10-13-2022
@demyr
1. Now I don't create any new package or something new.
2. I would like to support Long-living PHP officially in the future, but it is still a long way off.
3. I contributed Codeigniter4-Roadrunner, and https://github.com/monkenWu/CodeIgniter4-Burner is the next project of the creator of Codeigniter4-Roadrunner. So I recommend all of you see the package if you have interested in this topic.
First, currently there is no consensus to support or try to support Long-living PHP, so it would be nice that we would have that.
Second, if there is something wrong with CI4 code to work with them, I would like to fix it. So I want to know exact issues.
Then I would like to modify CI4 so that packages like CodeIgniter4-Burner work with less code.
RE: Long-living PHP support (Swoole/RoadRunner etc) - monkenWu - 10-15-2022
Hi, I'm glad this topic is being discussed.
Since I developed the CodeIgniter4-RoadRunner library, I have been trying to get CodeIgniter4 to run on a high performance php server.
In my work, I use Laravel for development. But in my spare time or side projects, I've been using CodeIgniter4.
I know that Laravel has a library called Laravel-Octane which is a perfect combination of Open Swoole and RoadRunner high performance server.
Similarly, for CodeIgniter4, I wanted to build a similar library to make the framework more attractive.
So I started the CodeIgniter4-Burner project to try to make CodeIgniter4 support multiple high-performance servers in a single library.
Like the idea of CodeIgniter being easy to use, my goal is to make CodeIgniter4-Burner work out of the box.
I encountered some issues in the development of the library, which I briefly mention here.
1. Request and Response objects do not implement the psr-7 interface.
Although the objects can be reconverted in some way, these conversions may cause some unnecessary performance overhead.
2. Unexpected direct output.
Although CodeIgniter4 uses the concept of Response objects, it is often found that the response is directly "echo" or header() declared in non-Response classes.
In high performance php servers, http output is handled by psr-7 Response or its proprietary Response object, and CodeIgniter4's "echo" behavior not only pollutes the buffer, but may also make the server unstable (like RoadRunner is sensitive to this).
3. debug-bar is not well designed.
In CodeIgniter4 the debug-bar handling seems to be out of the normal flow, it has a completely separate Request processing and Response output, which makes me overwrite the Debug-Bar related Classes and understand its logic very deeply. and in many cases I prefer CodeIgniter4 to be a black box and I don't want to overwrite the Class Method unless necessary.
4. The file upload class does not work correctly.
In php, we use move_uploaded_file() for file uploads, and CodeIgniter4 does too. However, on these long-living php servers, move_uploaded_file() does not work properly (because it is not a temp file handled by php, so this method will always fail). If the storage logic could be adjusted, then there would be no need for an additional file upload interface (which is how I currently handle it).
Above, I've summarized some of the issues I've encountered in development.
I have also solved these problems to some extent in CodeIgniter4-Burner. Currently, the library can provide http service, REST API, SESSION, database reconnection and file upload.
In the meantime, we are developing and testing CodeIgniter4-Burner in this slack channel, and there are some more deep discussions going on, so feel free to join us.
Thanks again for starting this discussion, and I hope CodeIgniter4 will become even better!
RE: Long-living PHP support (Swoole/RoadRunner etc) - vyatka - 10-15-2022
wow It's fantastic RFC =) God bless you
RE: Long-living PHP support (Swoole/RoadRunner etc) - MGatner - 10-17-2022
This is a very cool and ambitious project. CI4 definitely has a lot of roadblocks to be long-living, but my general opinion is: a well-designed project should work long-running by nature of being well-designed. In other words, we shouldn’t have to develop “for long-running” if we already following best practices, with very few exceptions (and I’m fine leaving those exceptions up to the library/scaffold).
That said, we have a lot of leaks and poor design in CI4 - many of which @monkenWu discovered during the Burner process.
Here’s my hunch: trying to get CI4 ready for long-running is going to be a very uphill battle against breaking changes - many of which would be fixed already by CI5 (PSR-7 is a great example). So while I don’t have any objections to making this a goal, I would rather see work done towards wrapping up CI4 and getting beta CI5 going. Using Burner (or similar) as a “miner’s canary” for CI5’s quality and compatibility would be a great opportunity to offer long-running support (or near to it) at the core of the framework.
RE: Long-living PHP support (Swoole/RoadRunner etc) - kenjis - 10-17-2022
"The problem is that what is best practice is not fully shared."
I agree overall, but one of the problems is that what is best practice is not fully shared.
To begin with, best practice is not so easily to be defined.
If we agree with supporting long-living PHP, we can say the following parts are not good.
Because simply they do not work as expected on long-living PHP:
- echo
- superglobals
- static variables
- is_cli()
- exit
RE: Long-living PHP support (Swoole/RoadRunner etc) - amit - 10-29-2022
I would like CodeIgniter to not rely on specific PSR interfaces as they change over time, and rather store its data in a simple array/object format.
For example, if CI has PSR X for logging and a third-party library asks for PSR Y then it is all just messy stuff.
The same applies to requests/responses etc.
An average developer can't handle this.
Further, it should also avoid depending on $_SERVER['xyz'] in its core like Negotiation or URL classes.
Instead, there should be transformer classes each one for Apache, ReactPHP, Swoole, RoadRunner etc. which can transform the server request/response to/from that CI-specific object.
In the Config\App it could be asked which server is being used and server-specific configuration files for CI could also be added.
Even others are trying to make compatibility but the overall experience isn't enjoyable. Like rather than improving, most of fellow developers are consuming time in debugging.
Best practices aren't standalone terms nor they attract developers itself alone. Best availability is also a major factor.
RE: Long-living PHP support (Swoole/RoadRunner etc) - ruslan - 12-25-2022
The question is does CI need to support Swoole, RoadRunner, etc
What for? Performance?
99% of performance problems are caused by bad application code, not by Nginx + PHP-FPM
CI is fast and loved because of its simplicity. This gives him power and strength. Let's leave it at that. Otherwise, it will become a big lazy monster like Laravel.