Hacker News new | comments | show | ask | jobs | submit login

Pardon me, but how is this better than queuing a job, and checking the status for that job instead? That's my standard MO when dealing with 3rd party API calls from a request.

How do you check for the status of the job? Do you hold the client connection open and block the process while you wait? Or do you notify the client through some other mechanism (polling, websocket, etc).

The advantage of evented I/O is that you don't have to do either of these things.

The way I do it now is tell the client to check back in X seconds depending on how many available workers compared to used workers there are.

I already have this wrapper for client side on iOS and working on a Batman.js version.

I usually do this for client side Login with different providers.

Say Facebook or Twitter. Login on the client, obtain token, send to server for validation. Server validates against Facebook/Twitter.

Server will tell the client to check back in X seconds. Client waits X seconds and does another check. Server is either done or not.

I rather do that, than to keep a request open. It's easier to manage on iOS as well since, say the user decides to check their email while the login is still processing.

Evented I/O sounds miraculous!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact