基于Lumen构建异步API：wait参数应部署在服务端还是客户端？

Let’s break down both approaches and weigh their pros and cons based on your setup (Lumen + Beanstalkd queue, 1-3s task duration, PHP client):

Server-side implementation of wait #

When you add a wait=true parameter to your API endpoint, the server workflow would look like this:

• Dispatch the job to Beanstalkd as normal
• Hold the HTTP connection open, polling your database periodically until the job finishes (or hits a predefined timeout)
• Return the final result directly once the job completes

Pros: #

• Simpler client code: Your PHP client only needs to send one request with wait=true and gets the result immediately—no extra polling logic required.
• Unified controls: You can enforce consistent timeout rules and polling intervals across all clients from the server side, avoiding inconsistent behavior.

Cons: #

• Resource bottlenecks: Holding open HTTP connections for 1-3 seconds per request ties up your Lumen worker processes. With high concurrency, you’ll quickly hit limits on how many simultaneous requests your server can handle.
• Increased database load: Server-side polling means your database gets hit repeatedly for every waiting request, adding unnecessary strain compared to letting clients check in on their own schedule.
• Timeout complexity: You’ll need to build robust timeout handling to avoid hanging processes, which adds extra code overhead (e.g., setting max wait times, cleaning up stale connections).

Client-side implementation of wait #

With this approach, the client takes responsibility for waiting:

• First, call your existing API to retrieve the job_id
• Repeatedly call your job status/result endpoint until the job is marked as completed (or the client hits its own timeout)
• Fetch the final result once the job is done

Pros: #

• Server efficiency: Your Lumen server stays lean—all requests are short-lived, so you can handle far more concurrent requests without worker exhaustion.
• Reduced DB pressure: Clients can adjust polling intervals (e.g., check every 500ms instead of 100ms) based on their needs, spreading out the load on your database.
• Flexibility: The client can customize timeout logic, retry behavior, and polling frequency to fit its specific use case—no rigid one-size-fits-all constraints from the server.

Cons: #

• Extra client code: You’ll need to write a bit more PHP code in your client to handle the polling loop, timeout checks, and error handling for failed status requests.
• Potential redundant requests: If a client polls too frequently, it could add unnecessary load, but this is easy to fix with sensible interval settings (e.g., start with 200ms, increase slightly if the job isn’t done).

Recommendation #

Given your task duration (1-3s) and PHP client, client-side implementation is the better default choice. It keeps your server scalable and avoids the resource overhead of holding connections open.

If you have a specific need to abstract polling logic (e.g., supporting many different client types that can’t implement their own polling), consider a hybrid optimized approach:

• Use server-side wait but replace database polling with Redis Pub/Sub. When the job completes, push the result to a Redis channel, and the server listens for that event instead of hitting the DB repeatedly. This cuts down DB load and makes the wait process more efficient.
• If you’re using a modern PHP runtime like Swoole or RoadRunner, handle waiting with coroutines so idle connections don’t block worker processes.

Whichever path you take, make sure to:

• Set clear timeout limits (e.g., max 5s wait time) to avoid hanging requests
• Return meaningful statuses (e.g., pending, completed, failed) along with the result or job_id
• Document the behavior clearly for anyone using your API

内容的提问来源于stack exchange，提问作者gdarko