3 ms·

Impressive range of libraries provided and the documentation is quite good. Seems a little strange that the benefits are touted of using the libraries over set

Impressive range of libraries provided and the documentation is quite good. Seems a little strange that the benefits are touted of using the libraries over setting up a dedicated queue service when the libraries rely on in memory queues. While the loss of the tracking data, should these queues fail, may not be worth the hassle of maintaining the dedicated infrastructure, there is a critical difference between the two approaches. These libraries are much more likely to impact application (or the servers the applications are running on) performance then queuing a message on another server.

ivolo 14y ago
the main idea is ease of integration. the developer doesn't have to write code to queue and dequeue, and the sys admin doesn't have to set up and support a queuing system. it's just a drop-in install. regarding the impact on application performance, each of the libraries has a maxQueueSize feature which stops accepting messages into the internal queue if the flushing can't keep up. you can check out how maxQueueSize works in our docs: https://segment.io/docs https://segment.io/docs
arscan 14y ago
This caught my eye as well, because the article talks about how big a pain it is to set up & maintain queuing servers, but then provides a solution that simply isn't as robust. But to be honest, the fact that they open sourced all these libraries and present them front-and-center for anybody interested makes up for that. There isn't any magic going on -- just some straightforward code that leverages language/runtime-appropriate mechanisms to queue up the messages. Its pretty easy to figure out if the solution meets your performance needs when you can see the actual code being run.
- bigiain 14y ago
  Sure, its not as robust as a generalised queuing system, but it's web analytics - the driving reason for queuing is more about high performance than about guaranteed message delivery. Lightweight and _fast_ in-memory queues seem like a perfectly adequate solution fr the problem domain, while being (as claimed) significantly less of a pain to set up than "traditional" queuing techniques.

ivolo 14y ago

the main idea is ease of integration. the developer doesn't have to write code to queue and dequeue, and the sys admin doesn't have to set up and support a queuing system. it's just a drop-in install. regarding the impact on application performance, each of the libraries has a maxQueueSize feature which stops accepting messages into the internal queue if the flushing can't keep up. you can check out how maxQueueSize works in our docs: https://segment.io/docs https://segment.io/docs

arscan 14y ago

This caught my eye as well, because the article talks about how big a pain it is to set up & maintain queuing servers, but then provides a solution that simply isn't as robust. But to be honest, the fact that they open sourced all these libraries and present them front-and-center for anybody interested makes up for that. There isn't any magic going on -- just some straightforward code that leverages language/runtime-appropriate mechanisms to queue up the messages. Its pretty easy to figure out if the solution meets your performance needs when you can see the actual code being run.

bigiain 14y ago
Sure, its not as robust as a generalised queuing system, but it's web analytics - the driving reason for queuing is more about high performance than about guaranteed message delivery. Lightweight and _fast_ in-memory queues seem like a perfectly adequate solution fr the problem domain, while being (as claimed) significantly less of a pain to set up than "traditional" queuing techniques.