raksoras

T

One of the complexity of the polling approach on a consumer side is having a long running poller. This is trivial to do in Java apps - start a polling thread - but not so straight forward in case of PHP apps, for example. In that case you'd have to setup a cron job or a separate polling script under some sort of process supervisor like systemd to poll periodically/continuously.

I wonder if the two approaches could be combined to simplify things for consumer apps at the cost of slightly more complexity on the producer side? Instead of POSTing the actual event data to webhook, the producer just uses consumer's webhook to "poke" it - to tell the consumer app "hey, you have new events waiting for you". On receiving the poke the consumer endpoint handler/PHP script can just turn around and do a GET to "/event" with anything > last downloaded event id query. That way you don't have to support long polling on the producer's servers and it's not a big problem if consumer misses couple of webhook "pokes". The next time it does receive a webhook "poke" successfully, it will download all the events and be all caught up. If real time notifications are not strictly required then producer side can even run the webhook dispatching code on a scheduled basis to coalesce multiple events in a single "poke" to a consumer to be more efficient, if desired.

A shameless plug: https://zipl.ink/ To send any open webpage to your mobile without any bluetooth or airdrop

I’m the said founder so Thanks for your kind words :)

https://www.scanfortable.com/

No traction so far most likely because of founder not good at sales.

Shameless plug: http://zipl.ink is the bookmarklet I use for the exact same purpose which also keeps record of the interesting links I zipped to my phone locally as a nice side effect

Something I hacked together for solving my own need.

Shameless plug: https://github.com/raksoras/koroutine

Shameless plug: https://github.com/raksoras/luaw

Why does k8s has this restriction that each pod/minion should be in its own subnet?

Right now it's just a HTTP server and REST framework. It's a very first release and I don't have any DB drivers for it yet- they would need to be non-blocking as you mentioned.

I have plans to write dbslayer like "access DB over REST" service as a companion to Luaw so that it can use any and all databases that have JDBC drivers available without having to write non-blocking driver specially for each new database. This kind of arrangement where DB connection pooling is abstracted out of application server itself has other advantages related to auto-scaling in cloud and red/black or "flip" code pushes at the cost of slightly more complex deployment.

All depends on how much spare time I actually get :(

I have used this idiom to great results in my project (https://github.com/raksoras/luaw). Basically, request:read() hooks up into libuv (node.js' excellent async IO library) event loop and then yields. Server is now free to run next coroutine. When socket underlying the first request is ready with data to read libuv event loop's callback gets fired and resumes original coroutine.

Coroutines are much better suited to event driven, non blocking IO code. Sorry for the shameless plug but I recently released my hobby project that uses Lua coroutines for nonblocking HTTP server: https://github.com/raksoras/luaw

Lua was quite pleasant to work with in this context!

Sorry for the shameless plug but I just released HTTP server based on Lua coroutines (https://github.com/raksoras/luaw) that pretty much follows the exact design from the OP article.

Luvit is an impressive project. However, as far as I can tell they still use Node.js style callbacks to handle asynchronous processing. IMHO Lua's coroutines are a natural match for event driven, async code and easier to use than nested callbacks. There are no callbacks in Luaw which makes writing nonblocking codes essentially as straight forward as blocking code. You never explicitly create coroutines or manage them in your code. Luaw automatically suspends HTTP request running in its own coroutine whenever read/write call is about to block and resumes it when the socket is ready for read/write

Event driven, non blocking HTTP app server for Lua inspired by Node.js. Uses Lua coroutines in place of nested callbacks to simplify application code.