How to send a message during a "real" process

[etshy]

I read your docs but I don't really understand how I can send a message during a process.

In my case, for exemple, I'd like to "dispatch/broadcast/push" (I don't know what's the correct term) a message from server to specific clients after an Article is created.

For example, I go on a page /article/create and I submit the form to create the Article.
As soon as the Article is created, I'd like to push a message for all the clients "subscribed" to this article's category. The response of this request must a "classic" Response, for the page to reload, etc., soI don't know what to do (and where) to send the message to the clients.

Where do I need to put the logic to create the StreamedResponse and send the message ?

ps : I'm using Symfony 4.2

[hhxsv5]

Hello, thanks for your question, depending on your scenario, maybe WebSocket is more suitable. You can use the asynchronous task queue to post tasks to the queue after creating the article and then broadcast it during the consumption process.

SSE is a protocol used to keep connections and continuously output data. Under FPM, an sse connection will occupy a process for a long time until Nginx times out.
If you have low performance requirements, you can use SSE.

1. Add a flag field to the article table to indicate whether it has been broadcast.
2. Create an SSE API, scan article table by the flag field in the Update callback.

[etshy]

Actually, with the Symfony Messenger Component, I have some asyn tasks to create a Notification object (that contained a link to the Article), so I'd like to send those Notificiation (in a new async Message, maybe?).
But if I make a async task, I don't understand how the StreamedResponse could be "sent" to a client.

Also your talked about Nginx, it can't work with apache ?

[hhxsv5]

The premise of using async task is to build a WebSocket server, you can try Swoole, WorkerMan, ReactPhp.

If you use SSE, when the client establishes a connection, SSE will start an infinite loop to hold the connection, ensure that the connection will not be closed, the loop body always checks the data state, and if the state meets some condition, the data is output to the client. This is cross-process, a connection occupies a process, variable/memory can't be shared, only share central storage such as MySQL and Redis.

The workers of Nginx and Apache are generally multi-process model, they support SSE.

[etshy]

Oh OK.
I didn't think it would take a process ad make some infinite loop (I thought it was a bit "smarter" than that).

So one connection is related to one client (tab ?) ? I guess there is some way to identify the client to send him specific data then ? how do we have that information (like a user ID, or anything) ?

That's not my case (and surely it will never be on the app I work on) bu if there iare a lot of users connected at the same, doesn't it really heavy on the server ? to have as much process ongoing, I mean.

[hhxsv5]

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

This document will help you understand how SSE works..

[etshy]

Thanks a lot.

For those who have the same question (how to send a message to a specific user) this simple answer help me : https://stackoverflow.com/a/35007680/4296405.

I don't know if it's what I searched but I'll give it a try.

[hhxsv5]

It turns out that your question is how to send a message with the specified user from the client. My answer is from the server 😂.

[etshy]

Well as the client is initiating the connection, I think the easiest solution is to include the user id or some identifiers in the URL used, so every users have its own SSE url.

That and I didn't really understand how to send data to a specific client from server, without sending the user id in the url...

[hhxsv5]

The URL contains the user ID, and the client establishes an SSE connection according to this URL. The server(FPM) occupies a process to keep the connection, and outputting data on the server is send a message to the connection of current user, but cannot send messages to the connections of other users. Because of the cross-process.