Cphalcon: [NFR]: Swoole integration

[PutinVladimir]

Today phalcon isn't fastest framework.

It's feature rich and superb architecture, but this do it at same time complicated and heavy inside. So its TTFB with PHP-FPM for typical app the same as other framework like laravel has and preloading doing this even more obvious.
Also a lot of other frameworks already has integration with swoole or ppm or roadrunner so they beat phalcon.

We can use swoole now, but sure need more closer integration and utilize swooles features.

[niden]

Can you explain a bit what this integration would do? For instance is Swoole going to be at the front end serving its web server and Phalcon behind it? What is a use case here?

[PutinVladimir]

Can you explain a bit what this integration would do? For instance is Swoole going to be at the front end serving its web server and Phalcon behind it?

Simply yes. We are right now can do something like this:

// ...Phalcon init code
// Swoole init
$http = new Swoole\HTTP\Server("127.0.0.1", 9501);

$http->on("start", function ($server) {
    echo "Swoole http server is started at http://127.0.0.1:9501\n";
});

$http->set(array(
        'worker_num' => swoole_cpu_num() * 5,
// ... other swoole config options
));

$application = new Application($di);

$http->on("request", function ($request, $response) use($application) {
    $response->write($application->handle($request->server["request_uri"])->getContent());
});

$http->start();

It works and speed up at least ten time.
But first it is not production way I guess.
And second swoole not only http\websocket\etc server, its also async db-connections pools, coroutines, fast serializer, queue, memory table etc.
Of Course, mainly need http\websocket server and db connections pools.
I don't sure how and on what layer integrate this. ServiceProvider, Domain, Container or where else...

[niden]

For the web server our friends from @McTekk have a script to start the server and it works just fine. Here is the link:

https://github.com/bakaphp/phalcon-api/blob/master/server

Now from what you mention i.e. to take advantage of other services, that is probably not going to be feasible without a huge amount of work on our end. For instance, you mention the db connection pools. That is admittedly a great feature but if say you use the MySQL client that Swoole offers, you will not be able to use Phalcon models, simply because the interfaces are not the same. Phalcon uses PHQL to perform the queries - internal language - which will not work with Swoole and what it expects. So either we will have to write some sort of a wrapper against the Swoole db drivers or they will have to change their code - which is not likely.

Also since there is no common interface between the two database drivers (Swoole vs Phalcon), means you cannot pass a Swoole db adapter in the DI container and expect it to work with the models in Phalcon or with other services such as the metadata for instance.

The fast serializer you probably can use it right now in your cache or others, so long as it implements the serializable interface.

If you are looking for a Phalcon framework that sits on top of Swoole then that is a different case. Sorry but I do not really understand what you mean about integration and how it would work. I know that some work needs to happen to ensure that you don't have to reinitialize the request all the time (as you see above in the bakaphp script) but that is it.

Also for the HTTP request, we do have plans on rewriting the HTTP layer to use only PSR-7 request responses, which will help with RoadRunner. So if Swoole handles PSR-7 then you would be able to plug and play so to speak.

[alexbusu]

@PutinVladimir You can use that approach already, as you put into example. Just make sure you overwrite the default request service (as it is making use of superglobals) and use a PSR-7 implementation instead (Phalcon 4 offers that already in Phalcon\Http\Message namespace). That is you want a separate Di container for each request. Otherwise, just instantiate a ServerRequest and populate with values from Swoole Request and call dispatcher(+router) and controller directly.

A bridge can be made to simplify the "end-user/developer" setup (that's what other frameworks did; hey, good idea to step up with such tool for Phalcon!). A separate Di container would be required for each Request (from a pool of containers, rotating them as the requests come). What do you think?

[PutinVladimir]

@alexbusu you are closest enough to what I want. But if doing pool of containers maybe should demonize it and retire swoole :)

[ruudboon]

I think this NFR is a bit too big and vague to be handled as a standalone NFR. I suggest we close this issue and if there's need for a specific functionality that helps using Phalcon in combination with an asynchronous framework in general it can be requested as a new issue that can be added to our voting list

[PutinVladimir]

@ruudboon disagree. It is too big and complex for phalcon developer but for end user its just one NFR as you said "using Phalcon in combination with an asynchronous framework in general"

[ruudboon]

What will you define as implemented in that case? You can already use Phalcon in combination with Swoole. Serialisers, tags etc can work.

[niden]

@ruudboon disagree. It is too big and complex for phalcon developer but for end user its just one NFR as you said "using Phalcon in combination with an asynchronous framework in general"

Does that mean that you volunteer to write it up? :) :)

This is indeed too big as a NFR. We need this to be split into smaller more specific tasks and then let the community vote for it on how important it is for everyone. Since we are using a smaller release cycle now for bugs and features, we need something that will not take months to fix - remember we do have day jobs ;)

If we create specific NFRs then we can reference the parent issue - this one for instance.

[Jurigag]

Tbh - this should be maybe separated project, like repository to take advantage of whole swoole. Like for example make redis, mysql, etc connection pools compatible with phalcon for coroutine usage etc.

Either provided just as composer package or optional extension like phalcon-swoole

I doubt we need this in core - not everyone will use it - how make extension larger and larger?

[ruudboon]

I'm closing this to keep a good overview of our pending issues. This issue is too big to add this to our NFR voting list.
I can imagine that a new project that depends on Phalcon like @Jurigag suggested could be something really interesting and could lead to an NFR here. It should be a detailed request of what changes are needed to consider it.
If the community wants to start a new repository with the integration that would be great!