Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Hello everyone,
I'm currently facing a challenge in my project. I want to create an event in Laravel that fetches data from an API and logs the process. My goal is to make this process as efficient as possible, so I thought about splitting the responsibilities into two separate listeners.
I have a log table with total_count, processed_count, and status columns, where the status can be 'pending', 'in progress', or 'success'. The first listener is responsible for registering the log and setting the status to 'in progress', followed by fetching the data from the API. I was hoping to pass this data to the second listener, which would then handle inserting the data into the database while updating the processed_count in the log table for each entry processed. Once all the data is processed, the status would be updated to 'success'.
The main motivation behind this approach is to ensure the API is only called once, given that the API URLs will vary but the data structure remains consistent. Additionally, the connection quality of these APIs varies, and the amount of data can be significant. Hence, I want to save resources by avoiding multiple API calls.
This entire process needs to run in the background. Given these requirements, I'm wondering if it's possible to have communication between listeners, or should I consolidate everything into a single listener? My concern is whether using a single listener would be as efficient.
Thank you!
You cannot chain jobs, and unless you queue the events, it will all be executed inline anyway.
If you want to update a table from a job, then you probably need to give the job the data it needs.
Bear in mind that jobs can run out of order.
Rather than events and listeners, I would fire a job to the queue and pass it the data it needs.
If you want a better answer, try editing your question into more readable paragraphs.
Thank you for the correction, I have edited the question to make it easier to read.
Slight update then. When you decide its time to collect from the API, create an entry in your table and dispatch a queued job and give it the model for the api collection. The job can run on a queue and update the table as it goes.
Thats all I would do. No need for events and listeners.
@nara014 You should be using queued jobs if you want this work to run in the background and its status to be tracked, and not event listeners. Event listeners run in the main application request cycle by default; not in the background. And you definitely don‘t have different listeners “talk” to each other. Each listener should be self-contained.
Thank you all for answering my question, does the event listener that implements should queue not behave like jobs? Previously I thought it was the same, only the delivery mechanism was different.
@nara014 The listeners would get queued, but like previously mentioned, listeners shouldn’t know about each other or be communicating with each other.
If you want jobs to have some intrinsic link with each other and a status representing the overall status of those group of jobs, then use job batching.
Please or to participate in this conversation.