Mixing
Where to subscribe for Redis Pub/Sub in Laravel?
I've been using Redis's Pub/Sub a bit in my application and so far it has been great. I am able to send out a Publish out of Laravel to a different backend process that is able to Subscribe, and eventually Publish an event back to Laravel.
The use case for the user looks like:
submit a form -> wait for a response (a few minutes) -> proceed with transaction
On the backend:
the form posts to a route, then to a controller that publishes this to a subscribed 3rd party (channel one), and eventually that 3rd party publishes back (channel two)
Main Issue: I don't know where the appropriate place to be for subscribing to the (channel two) and processing what gets published there.
Ideally, I'd be able to process Publish requests in two ways:
Letting the user know that their form has been processed and they can move onto the next step (probably with an update to a property a Vue component)
Storing information from the publish into my database.
In the docs, they have it in a Command, which if I try to use here would look like so:
public function handle()
{
Redis::subscribe('channel-two', function ($message) {
// update the client so that the user moves on
// send $message contents to the database
});
}
but that doesn't really seem ideal for me since I want this channel subscribed to 24/7, always listening. Even if it is in a Command, it is still apparent how I would best update the client.
Where in my Laravel project should I be subscribing at? Is there a best practice to respond to these events?
laravel redis publish-subscribe
asked Jan 1 at 16:32
StamsonStamson
247
add a comment |
I've been using Redis's Pub/Sub a bit in my application and so far it has been great. I am able to send out a Publish out of Laravel to a different backend process that is able to Subscribe, and eventually Publish an event back to Laravel.
The use case for the user looks like:
submit a form -> wait for a response (a few minutes) -> proceed with transaction
On the backend:
the form posts to a route, then to a controller that publishes this to a subscribed 3rd party (channel one), and eventually that 3rd party publishes back (channel two)
Main Issue: I don't know where the appropriate place to be for subscribing to the (channel two) and processing what gets published there.
Ideally, I'd be able to process Publish requests in two ways:
Letting the user know that their form has been processed and they can move onto the next step (probably with an update to a property a Vue component)
Storing information from the publish into my database.
In the docs, they have it in a Command, which if I try to use here would look like so:
public function handle()
{
Redis::subscribe('channel-two', function ($message) {
// update the client so that the user moves on
// send $message contents to the database
});
}
but that doesn't really seem ideal for me since I want this channel subscribed to 24/7, always listening. Even if it is in a Command, it is still apparent how I would best update the client.
Where in my Laravel project should I be subscribing at? Is there a best practice to respond to these events?
laravel redis publish-subscribe
asked Jan 1 at 16:32
StamsonStamson
247
add a comment |
I've been using Redis's Pub/Sub a bit in my application and so far it has been great. I am able to send out a Publish out of Laravel to a different backend process that is able to Subscribe, and eventually Publish an event back to Laravel.
The use case for the user looks like:
submit a form -> wait for a response (a few minutes) -> proceed with transaction
On the backend:
the form posts to a route, then to a controller that publishes this to a subscribed 3rd party (channel one), and eventually that 3rd party publishes back (channel two)
Main Issue: I don't know where the appropriate place to be for subscribing to the (channel two) and processing what gets published there.
Ideally, I'd be able to process Publish requests in two ways:
Letting the user know that their form has been processed and they can move onto the next step (probably with an update to a property a Vue component)
Storing information from the publish into my database.
In the docs, they have it in a Command, which if I try to use here would look like so:
public function handle()
{
Redis::subscribe('channel-two', function ($message) {
// update the client so that the user moves on
// send $message contents to the database
});
}
but that doesn't really seem ideal for me since I want this channel subscribed to 24/7, always listening. Even if it is in a Command, it is still apparent how I would best update the client.
Where in my Laravel project should I be subscribing at? Is there a best practice to respond to these events?
laravel redis publish-subscribe
asked Jan 1 at 16:32
StamsonStamson
247
I've been using Redis's Pub/Sub a bit in my application and so far it has been great. I am able to send out a Publish out of Laravel to a different backend process that is able to Subscribe, and eventually Publish an event back to Laravel.
The use case for the user looks like:
submit a form -> wait for a response (a few minutes) -> proceed with transaction
On the backend:
the form posts to a route, then to a controller that publishes this to a subscribed 3rd party (channel one), and eventually that 3rd party publishes back (channel two)
Main Issue: I don't know where the appropriate place to be for subscribing to the (channel two) and processing what gets published there.
Ideally, I'd be able to process Publish requests in two ways:
Letting the user know that their form has been processed and they can move onto the next step (probably with an update to a property a Vue component)
Storing information from the publish into my database.
In the docs, they have it in a Command, which if I try to use here would look like so:
public function handle()
{
Redis::subscribe('channel-two', function ($message) {
// update the client so that the user moves on
// send $message contents to the database
});
}
but that doesn't really seem ideal for me since I want this channel subscribed to 24/7, always listening. Even if it is in a Command, it is still apparent how I would best update the client.
Where in my Laravel project should I be subscribing at? Is there a best practice to respond to these events?
laravel redis publish-subscribe
laravel redis publish-subscribe
asked Jan 1 at 16:32
StamsonStamson
247
asked Jan 1 at 16:32
StamsonStamson
247
asked Jan 1 at 16:32
StamsonStamson
247
asked Jan 1 at 16:32
StamsonStamson
247
asked Jan 1 at 16:32
StamsonStamson
247
247
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Redis::subscribe is used in a command like in that example for listening on a given channel continuously.
From the docs:
First, let's setup a channel listener using the subscribe method. We'll place this method call within an Artisan command since calling the subscribe method begins a long-running process:
You'll want to run the command using a process manager like supervisor or pm2, much the same as the docs describe running queue listeners.
answered Jan 1 at 18:09
DigitalDrifterDigitalDrifter
8,6642625
So you would still recommend putting it in a Command? I suppose that works for running it 24/7 which is good. Any idea how I can get that event to update my client-side?
– Stamson
Jan 1 at 20:58
Yes having it run through a command is how I've run similar services. In order for the event to be received client side, you'll need to run a server that broadcasts the notifications to client subscribed to the appropriate channels. Laravel Echo is the frameworks offering that handles receiving notifications, while applications like laravel-echo-server, pusher and most recently laravel-websockets handle the broadcasting.
– DigitalDrifter
Jan 1 at 23:26
As an aside, I've recently integrated laravel-websockets into a major project and have been very happy with the results. It is a drop-in replacement for pusher purpose built to work with Laravel. I highly recommend you look into it first.
– DigitalDrifter
Jan 1 at 23:29
Aren’t those all Redis replacements? I feel like Redis pub/sub has done 99% of what I need it to do, so it doesn’t really feel right pulling in a whole different library just to get the Publishes down to client side.
– Stamson
Jan 2 at 0:11
No, they are websocket libraries for client-server communication. Redis is still an integral part of the system.
– DigitalDrifter
Jan 2 at 0:47
|
show 1 more comment
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53997104%2fwhere-to-subscribe-for-redis-pub-sub-in-laravel%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Redis::subscribe is used in a command like in that example for listening on a given channel continuously.
From the docs:
First, let's setup a channel listener using the subscribe method. We'll place this method call within an Artisan command since calling the subscribe method begins a long-running process:
You'll want to run the command using a process manager like supervisor or pm2, much the same as the docs describe running queue listeners.
answered Jan 1 at 18:09
DigitalDrifterDigitalDrifter
8,6642625
So you would still recommend putting it in a Command? I suppose that works for running it 24/7 which is good. Any idea how I can get that event to update my client-side?
– Stamson
Jan 1 at 20:58
Yes having it run through a command is how I've run similar services. In order for the event to be received client side, you'll need to run a server that broadcasts the notifications to client subscribed to the appropriate channels. Laravel Echo is the frameworks offering that handles receiving notifications, while applications like laravel-echo-server, pusher and most recently laravel-websockets handle the broadcasting.
– DigitalDrifter
Jan 1 at 23:26
As an aside, I've recently integrated laravel-websockets into a major project and have been very happy with the results. It is a drop-in replacement for pusher purpose built to work with Laravel. I highly recommend you look into it first.
– DigitalDrifter
Jan 1 at 23:29
Aren’t those all Redis replacements? I feel like Redis pub/sub has done 99% of what I need it to do, so it doesn’t really feel right pulling in a whole different library just to get the Publishes down to client side.
– Stamson
Jan 2 at 0:11
No, they are websocket libraries for client-server communication. Redis is still an integral part of the system.
– DigitalDrifter
Jan 2 at 0:47
|
show 1 more comment
Redis::subscribe is used in a command like in that example for listening on a given channel continuously.
From the docs:
First, let's setup a channel listener using the subscribe method. We'll place this method call within an Artisan command since calling the subscribe method begins a long-running process:
You'll want to run the command using a process manager like supervisor or pm2, much the same as the docs describe running queue listeners.
answered Jan 1 at 18:09
DigitalDrifterDigitalDrifter
8,6642625
So you would still recommend putting it in a Command? I suppose that works for running it 24/7 which is good. Any idea how I can get that event to update my client-side?
– Stamson
Jan 1 at 20:58
Yes having it run through a command is how I've run similar services. In order for the event to be received client side, you'll need to run a server that broadcasts the notifications to client subscribed to the appropriate channels. Laravel Echo is the frameworks offering that handles receiving notifications, while applications like laravel-echo-server, pusher and most recently laravel-websockets handle the broadcasting.
– DigitalDrifter
Jan 1 at 23:26
As an aside, I've recently integrated laravel-websockets into a major project and have been very happy with the results. It is a drop-in replacement for pusher purpose built to work with Laravel. I highly recommend you look into it first.
– DigitalDrifter
Jan 1 at 23:29
Aren’t those all Redis replacements? I feel like Redis pub/sub has done 99% of what I need it to do, so it doesn’t really feel right pulling in a whole different library just to get the Publishes down to client side.
– Stamson
Jan 2 at 0:11
No, they are websocket libraries for client-server communication. Redis is still an integral part of the system.
– DigitalDrifter
Jan 2 at 0:47
|
show 1 more comment
Redis::subscribe is used in a command like in that example for listening on a given channel continuously.
From the docs:
First, let's setup a channel listener using the subscribe method. We'll place this method call within an Artisan command since calling the subscribe method begins a long-running process:
You'll want to run the command using a process manager like supervisor or pm2, much the same as the docs describe running queue listeners.
answered Jan 1 at 18:09
DigitalDrifterDigitalDrifter
8,6642625
Redis::subscribe is used in a command like in that example for listening on a given channel continuously.
From the docs:
First, let's setup a channel listener using the subscribe method. We'll place this method call within an Artisan command since calling the subscribe method begins a long-running process:
You'll want to run the command using a process manager like supervisor or pm2, much the same as the docs describe running queue listeners.
answered Jan 1 at 18:09
DigitalDrifterDigitalDrifter
8,6642625
answered Jan 1 at 18:09
DigitalDrifterDigitalDrifter
8,6642625
answered Jan 1 at 18:09
DigitalDrifterDigitalDrifter
8,6642625
answered Jan 1 at 18:09
DigitalDrifterDigitalDrifter
8,6642625
8,6642625
So you would still recommend putting it in a Command? I suppose that works for running it 24/7 which is good. Any idea how I can get that event to update my client-side?
– Stamson
Jan 1 at 20:58
Yes having it run through a command is how I've run similar services. In order for the event to be received client side, you'll need to run a server that broadcasts the notifications to client subscribed to the appropriate channels. Laravel Echo is the frameworks offering that handles receiving notifications, while applications like laravel-echo-server, pusher and most recently laravel-websockets handle the broadcasting.
– DigitalDrifter
Jan 1 at 23:26
As an aside, I've recently integrated laravel-websockets into a major project and have been very happy with the results. It is a drop-in replacement for pusher purpose built to work with Laravel. I highly recommend you look into it first.
– DigitalDrifter
Jan 1 at 23:29
Aren’t those all Redis replacements? I feel like Redis pub/sub has done 99% of what I need it to do, so it doesn’t really feel right pulling in a whole different library just to get the Publishes down to client side.
– Stamson
Jan 2 at 0:11
No, they are websocket libraries for client-server communication. Redis is still an integral part of the system.
– DigitalDrifter
Jan 2 at 0:47
|
show 1 more comment
So you would still recommend putting it in a Command? I suppose that works for running it 24/7 which is good. Any idea how I can get that event to update my client-side?
– Stamson
Jan 1 at 20:58
Yes having it run through a command is how I've run similar services. In order for the event to be received client side, you'll need to run a server that broadcasts the notifications to client subscribed to the appropriate channels. Laravel Echo is the frameworks offering that handles receiving notifications, while applications like laravel-echo-server, pusher and most recently laravel-websockets handle the broadcasting.
– DigitalDrifter
Jan 1 at 23:26
As an aside, I've recently integrated laravel-websockets into a major project and have been very happy with the results. It is a drop-in replacement for pusher purpose built to work with Laravel. I highly recommend you look into it first.
– DigitalDrifter
Jan 1 at 23:29
Aren’t those all Redis replacements? I feel like Redis pub/sub has done 99% of what I need it to do, so it doesn’t really feel right pulling in a whole different library just to get the Publishes down to client side.
– Stamson
Jan 2 at 0:11
No, they are websocket libraries for client-server communication. Redis is still an integral part of the system.
– DigitalDrifter
Jan 2 at 0:47
So you would still recommend putting it in a Command? I suppose that works for running it 24/7 which is good. Any idea how I can get that event to update my client-side?
– Stamson
Jan 1 at 20:58
So you would still recommend putting it in a Command? I suppose that works for running it 24/7 which is good. Any idea how I can get that event to update my client-side?
– Stamson
Jan 1 at 20:58
Yes having it run through a command is how I've run similar services. In order for the event to be received client side, you'll need to run a server that broadcasts the notifications to client subscribed to the appropriate channels. Laravel Echo is the frameworks offering that handles receiving notifications, while applications like laravel-echo-server, pusher and most recently laravel-websockets handle the broadcasting.
– DigitalDrifter
Jan 1 at 23:26
Yes having it run through a command is how I've run similar services. In order for the event to be received client side, you'll need to run a server that broadcasts the notifications to client subscribed to the appropriate channels. Laravel Echo is the frameworks offering that handles receiving notifications, while applications like laravel-echo-server, pusher and most recently laravel-websockets handle the broadcasting.
– DigitalDrifter
Jan 1 at 23:26
As an aside, I've recently integrated laravel-websockets into a major project and have been very happy with the results. It is a drop-in replacement for pusher purpose built to work with Laravel. I highly recommend you look into it first.
– DigitalDrifter
Jan 1 at 23:29
As an aside, I've recently integrated laravel-websockets into a major project and have been very happy with the results. It is a drop-in replacement for pusher purpose built to work with Laravel. I highly recommend you look into it first.
– DigitalDrifter
Jan 1 at 23:29
Aren’t those all Redis replacements? I feel like Redis pub/sub has done 99% of what I need it to do, so it doesn’t really feel right pulling in a whole different library just to get the Publishes down to client side.
– Stamson
Jan 2 at 0:11
Aren’t those all Redis replacements? I feel like Redis pub/sub has done 99% of what I need it to do, so it doesn’t really feel right pulling in a whole different library just to get the Publishes down to client side.
– Stamson
Jan 2 at 0:11
No, they are websocket libraries for client-server communication. Redis is still an integral part of the system.
– DigitalDrifter
Jan 2 at 0:47
No, they are websocket libraries for client-server communication. Redis is still an integral part of the system.
– DigitalDrifter
Jan 2 at 0:47
|
show 1 more comment
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53997104%2fwhere-to-subscribe-for-redis-pub-sub-in-laravel%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
