Yii2: [dicussion] Yii2 and ReactPHP

[Faryshta]

This post is mostly to gather ideas for an integration between ReactPHP and Yii2 since I think that effort would require a mayor refactorization of Yii2 framework and won't be achieved in the near future.

For the sake of simplicity lets say we will be talking about yii2-basic-application repository with one ReactPHP server instance.

The first issue to notice is that the Yii::$app property will have to get rewritten almost from scratch or fully deprecated. Some components such as

• Yii::$app->db
• Yii::$app->urlManager
• Yii::$app->assetManager

and all the modules will get greatly benefited since they will be created once for all requests and we can optimize based on that. But the great majority of components will have to get dettached from Yii::$app such as

• Yii::$app->user
• Yii::$app->request
• Yii::$app->response
• Yii::$app->controller
• Yii::$app->view

all of them are heavily used inside the core and i know i use them a lot on my code. but since the same instances will be use for every request that means parallel requests will leak data on each other.

that means the controllers will change too, specially with how the actions are processed.

widgets and by extension assets will need to receive the view object and the response object to be processed.

model logic probably will require little to no rewritting and i think queries will get a performance boost along with possibilities for enhancements.

[cebe]

Can you elaborate more on why you want to write your own HTTP server in ReactPHP instead of using a traditional stack via CGI or modphp? I think this use case is mostly out of scope of Yii. Related to #13922.

[Faryshta]

for example keeping a connection alive to show real time stats on usage/performance without clodging ajax requests.

i think @mikk150 brings very good arguments on the discussion you linked since react pattern was written to solve all the use cases he mentions.

and what @klimov-paul said is also true, supporting the react pattern would imply rewriting a lot of helpers and behaviors.

[cebe]

for example keeping a connection alive to show real time stats on usage/performance without clodging ajax requests.

there is Event Sourcing for that and you can write a ReactPHP worker for that. That one will however not work after the controller-action principle so you would not use the normal routing and controller-action stack with Request and Response of Yii for that.

I do not think react is to replace normal HTTP request workflow but to add a way writing workers and daemons that solve other tasks.

[Faryshta]

I do not think react is to replace normal HTTP request workflow but to add a way writing workers and daemons that solve other tasks.

i never said otherwise.

[mikk150]

I do not think, that this will work without practically rewriting everything(even AR)

React is cool(I have it working in one of my Yii2 applications) but deep integration will be painful and I think essentially not worth it

[mikk150]

but

Yii::$app->user
Yii::$app->request
Yii::$app->response
Yii::$app->controller
Yii::$app->view

Should get detached from application..

[Faryshta]

i don't think ar would need rewrite but almost everything else would.

i want to discuss all the implications of using yii2 and react php together in a not-so-near future and keep track on any change this topic has later on.

the react pattern is becoming popular mostly due to node.js and react.js so its good to keep an eye on it.

[mikk150]

@Faryshta AR needs to be rewritten in order to react to make sense.. React cannot make it's magic when Yii-s AR is blocking event loop

[Faryshta]

how would ar block an event loop?

[mikk150]

Does Yii AR have callback method? does it make ANY! approaches to NOT block if it is fetching data from DB?

[Faryshta]

i honestly don't understand what you are asking. can you give me an example of said callbacks?

[mikk150]

The thing is... Right now I do not need react.. Threads work well enough..

I agree, that others may need it, but the way how PHP is right now(everything blocks) it's not worth it

In PHP right now, if you want to do anything remotely async you cannot use vast majority of PHP-s in-built methods

If you want to use Yii-s AR as-is in react, Yii-s AR will block event loop and negate all the awesome effects of event loop performance gains

[mikk150]

To make AR work, we really need to start supporting things like

Book::find()->where(['title', 'like', '%Harry Potter%'])->then(function ($results) {

});

essentially a promise.

but that would mean, that controller gives in an promise

that would mean that request is an promise

that would mean that response is a promise

and so on

[Faryshta]

which operations on the MVC core would require promises? now that i think about it widgets might get optimized with promises too, specially big ones but that could cause a syntax nightmare.

[mikk150]

@Faryshta No operation in MVC requires promise, but I suggest them because otherwise you would have callback hell and we all know how it ended up in Javascript..

Let's not make same mistake as Javascript did

[ioncode]

as i understand (having a lot exp. with yii, node.js and angular) you want to bring async in php, using node.js like (reactphp) libevent model

now in big projects we must use many different technologies together to build one app with one function - serve typical requests as fast as it can

nginx, php-fpm, opcache, redis, rabbitMQ, supervisor, cli php workers, node.js websockets, and more and more layers for one simple thing - serve same concurent requests with different data fast and reuse resources if it possible

in heavy apps i think raw node.js is better than all other multilayer solutions

if reactphp/symphony/drupal/php-pm/libevent can introduce ready to use realization in production - php will have second (seventh) chance to beat node.js

[cebe]

The strength of PHP is that requests are independent so you can scale by adding web worker servers behind a load balancer that all work independently in parallel. With a single server written in PHP which holds all the state in memory that is not possible. I do not really see the advantage.

[Faryshta]

@cebe most of the use cases for this issue are discussed on #13992 . I don't think we should discuss the usability of the react pattern here.

This is not a discussion if independent requests are better than asynchronous requests, its about what needs to be done to support asynchronous requests using reactphp.

[Sammaye]

I might be missing something here but it sounds like trying to make PHP do what node.js and socket.io was created for basically

[klimov-paul]

I can see absolutely no benefit of LibEvent based solution in PHP - it eliminates any benefit of the language itself. All standard functionas and libraries will be useless for LibEvent-driven applications:

• file realated functions like file_put_contents, mkdir, chmod and so on are blocking-type ones, which make them unusable for libevent-based application
• database access layer including PDO is blocking-type, which make it unusable too
• such lbraries like memcache and memcached are blocking-one, which also makes them unusable
• extensions like mongodb and other wrappers around sockets have same problem

What is the sence to recreating NodeJS using PHP, while ALL PHP standard functions and libraries becomes useless? Why so not use NodeJS or other specific technology instead? What is the benefit of twisting the PHP - keep the variable names prefixed with $ sign, can't you live without it?

This is not a matter of adjusting Yii to support LibEvent - it is a matter of inventing another PHP framework (or even PHP sub-language) for this. Such tasks requires recreating low-level protocols for MySQL, MSSQL, MemCache and all other external services from scratch. This taks lies beyond the scope of Yii and knowledges and skills of the core team.

If you wish to continue disscussion about twisting PHP into NodeJS, please use a forum or something like http://stackoverflow.com/ instead.

[dynasource]

valid points. Still a very interesting concept though.