Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

enthusiast14's avatar

API improvements

Hi Laravel experts

I made some API endpoints in laravel, there are many calls to the API from android apps per day. mobile phone app will just call the API with data and API methods will just save data to mysql table using model::create methods.

Now question is are there any laravel techniques and technologies available to improve API performance and catching errors if any with respect to number of API calls from app?. Let's say there are many api calls at the same time from app in various mobile phones, it can be 500/1000 calls at the same time, or let's say there are more than 2/3 thousands api calls each day. So in these cases what i have to do so that API works well and don't break and performance doesn't decrease.

I know about laravel queue but in this case do i need to use queue because there are no time consuming tasks via api, Api just saves app posted data to mysql ?. Or if i need to use queue then in what cases i can use it ? and i guess running the queue worker in shared server is a big hassle too.

Please reply me, ask me if i am unable to express my views. It's important API job i am handling right now.

0 likes
5 replies
bobbybouwmann's avatar

Well, it depends if all those requests come in at the same time. If you get over 1000 requests a day, but not at the same time you shouldn't worry.

If you do get a lot of requests at the same time you probably won't be able to use shared hosting anymore. In that case, you need to make sure you have enough application capacity to handle all those requests. Next to that you also need to have enough database connections available. These are just a few things you have to keep in mind.

A queue can help you here as well. Instead of inserting the data right away, you simply put the data on the queue and let a job insert the data. This way, you can easily return a response without needing to hit the database. The queue can then take it's time to process everything. This is really only needed if you handle 100.000 records or more within a few seconds. In general, your database is fast enough to handle all of that.

2 likes
enthusiast14's avatar

Thanks for your reply, you wrote a dot after 100 (100.000 records) instead comma, i think you meant 100 thousand records. It's a huge number then which i think not hitting right now. But you missed a comment about installing headache of queue worker in shared/vps server.

want to hear more technologies from you guys to assist my API implementation.

automica's avatar

@enthusiast14 if you on small scale at the moment, you won't necessarily need to add the queue quite yet.

We have an api which supports 2 mobile phone apps (for financial services transactions) and we're not using queue workers yet.

as @bobbybouwmann says though, at some point you'll need to scale, so if there is a problem running a queue worker on a shared vps, its worth planning what type of server it won't be a headache installing on before you need it.

bobbybouwmann's avatar

It sounds to me that you don't need a queue at all and that your current server can handle the load just fine

2 likes

Please or to participate in this conversation.