4 ms·

Looks like event-driven systems are all the rage now! I feel there's still too much competition/innovation in the message queue space though. Too many choices,

by vemv 8y ago

Looks like event-driven systems are all the rage now! I feel there's still too much competition/innovation in the message queue space though. Too many choices, with maddeningly different characteristics. And seemingly you can tweak most of those to behave somewhat similarly between them, which makes judgement even harder.

denormalfloat 8y ago
Isn't competition good for consumers though? Eventually, one of these network architectures will become more popular and we don't have to try them all out personally ourselves. I benefit greatly from people in the 90s testing out HTTP over other competing protocols, which, at the time may not have been obviously better.
jimbokun 8y ago
"I feel there's still too much competition/innovation in the message queue space though." Interesting, to me Kafka seems like the clear winner and the obvious choice for all of my queuing needs. What am I missing out on from other queuing systems?
- jimsmart 8y ago
  I recently evaluated a bunch of different messaging systems, and found NATS to have the widest support for different client languages, plus those clients are also maintained by the same parent company. With other MQs we have used, we have found much variety in the quality of the client libs. YYMV.
cryptonector 8y ago
As it should be. The question is: can you use HTTP to transport event notifications? Actually, can you use TCP to transport event notifications? Yes, you can, but it's a bit unwieldy because you need some sort of keepalive / heartbeat with which to distinguish inactivity from transient network problems (and then attempt to reconnect). Then again, even if you were using UDP you'd have to do some sort of keepalive / heartbeat. I use an HTTP server that supports "tail -f" via chunked transfer-encoding responses to indeterminate byte range requests (Range: bytes=${offset}-) that don't end until the file is removed, renamed away, or replaced (renamed over). This server also supports weak ETags constructed from (device ID, inode number, generation number), If-Match, and If-None-Match. This allows clients to GET a resource whose body is the event stream and hang in there waiting for events. Again, you need to add a heartbeat in the event stream as HTTP chunked transfer-encoding does not have this, and you need to detect network problems. But otherwise this works fantastically well and it is HTTP and RESTful.

by vemv 8y ago

denormalfloat 8y ago

Isn't competition good for consumers though? Eventually, one of these network architectures will become more popular and we don't have to try them all out personally ourselves. I benefit greatly from people in the 90s testing out HTTP over other competing protocols, which, at the time may not have been obviously better.

jimbokun 8y ago

"I feel there's still too much competition/innovation in the message queue space though." Interesting, to me Kafka seems like the clear winner and the obvious choice for all of my queuing needs. What am I missing out on from other queuing systems?

jimsmart 8y ago
I recently evaluated a bunch of different messaging systems, and found NATS to have the widest support for different client languages, plus those clients are also maintained by the same parent company. With other MQs we have used, we have found much variety in the quality of the client libs. YYMV.

cryptonector 8y ago

As it should be. The question is: can you use HTTP to transport event notifications? Actually, can you use TCP to transport event notifications? Yes, you can, but it's a bit unwieldy because you need some sort of keepalive / heartbeat with which to distinguish inactivity from transient network problems (and then attempt to reconnect). Then again, even if you were using UDP you'd have to do some sort of keepalive / heartbeat. I use an HTTP server that supports "tail -f" via chunked transfer-encoding responses to indeterminate byte range requests (Range: bytes=${offset}-) that don't end until the file is removed, renamed away, or replaced (renamed over). This server also supports weak ETags constructed from (device ID, inode number, generation number), If-Match, and If-None-Match. This allows clients to GET a resource whose body is the event stream and hang in there waiting for events. Again, you need to add a heartbeat in the event stream as HTTP chunked transfer-encoding does not have this, and you need to detect network problems. But otherwise this works fantastically well and it is HTTP and RESTful.