Queueing requests in Laravel

[sammyjo20]

Queueing requests in Laravel

[Sammyjo20]

Yeah, that is a way to do it @niladam but should we require people to use that trait if they are queuing requests?

The other thing I can think of is to do something like a queueable connector...

Connector::queue(new SomeRequest);

Then if you want to add queuing functionality, you just add the queuing interface/trait to your connector.

I can try to make it work with both the connector and request like other features

[boryn]

Hi @James4645

Why don't you just create a SyncIntegrationApiJob() and you would SyncIntegrationApiJob::dispatch() it when needed? It's the natural Laravel way to go.

[Sammyjo20]

That sounds cool, I wanted to incorporate it with queues so it could auto-retry, but you could quite easily wrap a Saloon request in a queued job and then you have the power to handle failures/retry logic yourself.

A built in Saloon version might go against Laravel’s patterns for where queued jobs are stored. If this was a new addition, what features would you like?

[James4645]

Sure you could wrap it in a Job but that seems overly verbose. For example with a Notification in Laravel it can queue itself without you having to wrap it in a job. I use another package called Laravel-Excel that imports and exports data with Excel and those classes can queue themselves too.

Perhaps if you have complex logic around processing the response it would probably make more sense to use a Job to keep the response processing logic isolated. But for simple response handling like just verifying it was successful or maybe saving the response to the DB I think I'd be more convenient to just add ShouldQueue and a handle or other method with what to do with the response.

As far as specific features around it basically if I could control if it needs to retry or be considered a fail job based on the response that should be sufficient. Some things you can assume like retry with a 5xx response or mark as failed with a 4xx response. But for example some API error states will still give a 200 response code but show the error in the body.

Ultimately I just like the idea of not having to add another class. And of being able to call the request directly in my code so I can see exactly what's being called without it being hidden in a Job class but still getting the benefits of the queue.

[Sammyjo20]

Thanks for your time @James4645 for putting this up here, however I don't think I will be implementing this within the next 4-8 weeks. I have added it to my task board so I can remember it.

The reason why I'm putting off just allowing you to add "ShouldQueue" because I feel I could add a couple of helper methods on top and I'd really like to understand how it all works first before introducing it. It would certainly be cool though.

Thanks again!

[niladam]

I think this could be a great addition. Do you have any plans for this ? I'd maybe be able to help if you can expand on your plans ?:)

[Sammyjo20]

I’d be happy to re-open the issue so we can discuss how this could be implemented! Perhaps it could be something the saloon-laravel package could come bundled with?

Now that Connectors are required, to queue a single request, we would need someone to pass in or resolve a new connector instance?

[niladam]

Yeah. I think you're right. It could probably be tackled within the laravel package.

As for the requiring of the connectors, can't these be resolved via the HasConnector plugin which basically allows you to get the connector simply by:

$request = new ReadFromApiRequest();
$request->connector();

Or is there something that i'm missing ?

[niladam]

If we're doing this with send, why not with queue? To me it looks like it's keeping the same pattern;)

[Sammyjo20]

Hey @niladam / @James4645 I'm just wondering what would be a practical use case to queue a request to be sent and not have it wrapped in your own job? The only thing I can think of is for creating/deleting things on a remote server, but I still imagine it would be useful to make your own job so you can handle errors properly and catch if anything goes wrong. If Saloon had a queue feature, you wouldn't be able to customise anything other than it just sending a request, which I'm unsure is that helpful?

[Sammyjo20]

Sorry guys, after a bit of back and forth in my mind I don't think I'm going to introduce this functionality right now - as always I'm open for implementing this in the future but I can't see a way this is that useful - I think most people would use Laravel's service container to resolve the connector, and then send the request inside of their own jobs.

I also had a PR which allows the connector to be serialized, but I think this one will have to go back on the back-burner for a bit.

Thanks for your help!

[James4645]

I was interested to see this closed as completed only to realize reading the comment it was never completed. Without this and with needing to write my own jobs I haven't seen any value this package adds and have just written jobs that call the Laravel HTTP Client. Because IMO what's the purpose of writing a specific request class to just wrap it in a queued job.

…

________________________________ From: Sam Carré ***@***.***> Sent: Friday, June 23, 2023 12:07 PM To: Sammyjo20/Saloon ***@***.***> Cc: James4645 ***@***.***>; Mention ***@***.***> Subject: Re: [Sammyjo20/Saloon] Queueing requests in Laravel (Issue #38) Closed #38<#38> as completed. — Reply to this email directly, view it on GitHub<#38 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ASTNTKVFP5LDGTNNGYHVYNDXMXSNJANCNFSM5ORQ3TVQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Sammyjo20]

Hey @James4645

I totally understand, you won’t want to make unnecessary classes in your code. However, Saloon’s request classes are designed so you can keep all the logic needed to make a third party API call anywhere in your application, they aren’t really designed to be able to take the response and do something with them afterwards right within the same class.

Now it’s interesting that you say that, I’ve not come across this requirement for anyone else, but I try to consider everyone’s ideas and opinions as potential improvements to the library. Please could you explain your use case? From within Saloon, you can actually register middleware inside an individual request, like this…

class SomeRequest extends Request
{

    public function boot(PendingRequest $pendingRequest)
    {
        $pendingRequest->onResponse(function (Response $response) { 
              // Do something with the response
        });
}

}

Then if you wanted it to be queued, you could use Laravel’s dispatch helper…

dispatch(fn (SomeConnector $connector) => $connector->send(new SomeRequest)

You could even use the HasConnector trait on your request if you want to define the connector on the request to save instantiating this every time (this is in the docs under the sending requests section)

I will put a question out to the community to see if it’s something people are after and if it’s desired, I will consider it for v3 :)

Thanks!
Sam

[James4645]

Now I am just confused. I didn't say anything about the response, I just need to queue the request so I am not slowing down my response to the user who triggered the API call and it seems pointless to me to make a job to call this when I can do the HTTP call in my job.

…

________________________________ From: Sam Carré ***@***.***> Sent: Thursday, June 29, 2023 2:38 PM To: Sammyjo20/Saloon ***@***.***> Cc: James4645 ***@***.***>; Mention ***@***.***> Subject: Re: [Sammyjo20/Saloon] Queueing requests in Laravel (Issue #38) Hey @James4645<https://github.com/James4645> I totally understand, you won’t want to make unnecessary classes in your code. However, Saloon’s request classes are designed so you can keep all the logic needed to make a third party API call anywhere in your application, they aren’t really designed to be able to take the response and do something with them afterwards right within the same class. Now it’s interesting that you say that, I’ve not come across this requirement for anyone else, but I try to consider everyone’s ideas and opinions as potential improvements to the library. Please could you explain your use case? From within Saloon, you can actually register middleware inside an individual request, like this… class SomeRequest extends Request { public function boot(PendingRequest $pendingRequest) { $pendingRequest->onResponse(function (Response $response) { // Do something with the response }); } } Then if you wanted it to be queued, you could use Laravel’s dispatch helper… dispatch(fn (SomeConnector $connector) => $connector->send(new SomeRequest) You could even use the HasConnector trait on your request if you want to define the connector on the request to save instantiating this every time (this is in the docs under the sending requests section) I will put a question out to the community to see if it’s something people are after and if it’s desired, I will consider it for v3 :) Thanks! Sam — Reply to this email directly, view it on GitHub<#38 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ASTNTKRMNC36T55UKR7DR7LXNXYU7ANCNFSM5ORQ3TVQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Sammyjo20]

Sounds like Saloon isn’t for you right now @James4645. Have a great day :)

[Sammyjo20]

Yeah that's a good idea @boryn - you could then pass in the Saloon request you want to send.

[James4645]

That's quite frankly a poor answer. The need to que requests isn't special or u ique it's quite a common way to use APIs. So you ignoring the use case is quite frankly bizzaire.

…

________________________________ From: Sam Carré ***@***.***> Sent: Friday, June 30, 2023 3:11 PM To: Sammyjo20/Saloon ***@***.***> Cc: James4645 ***@***.***>; Mention ***@***.***> Subject: Re: [Sammyjo20/Saloon] Queueing requests in Laravel (Issue #38) Sounds like Saloon isn’t for you right now @James4645<https://github.com/James4645>. Have a great day :) — Reply to this email directly, view it on GitHub<#38 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ASTNTKWPBLSHSTQJE357ZMLXN5FKPANCNFSM5ORQ3TVQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>