Hacker News Reader

Comment by mperham | Hacker News Reader

For those of you pointing out flaws, remember you are picking apart a pre-1.0, just launched project. We're all hackers and startup people right? Think MVP, no one can ship a perfect system completely finished.

View on HN

Just remember, grumpy HN comments are .001% of people viewing the homepage and clicking the link to your site.

Your potential customers know better than to get their opinions from reading these comments :)

This is a strong defensive stand, especially coming from the author. Picking things apart with you is better than a "great work and now next post" comment.

Aren't the flaws flaws in the concept, rather than the implementation, though? Are those likely to be improved on?

Thanks Mike for creating Sidekiq and this. pre-1.0 is alright with me for showing it on HN.

The only flaw here seems to be a lack of use-case... why not just add an HTTP API to Sidekiq instead, if it doesn't already have it? That way the value of the queue logic and semantics can be offered to any external client.

Sidekiq is not a server, it's a Ruby worker process. Redis is the server and I can't build a fast, easy to use embedded queue system on top of Redis.

Can't Sidekiq just run as a standalone process? It can take a connection string to use existing Redis/RDBMS with option to use embedded server maybe. You can just package it with Redis in a container too.

Although to be honest, the basics of a work queue are well covered now with the evolution of cloud services and other databases and message systems.

Sidekiq is Ruby only. That won't support one of my key goals with Faktory: polyglot. Background jobs can benefit applications written in many languages.

There's many different tools and many different users. No one choice is appropriate for all. I hope some people find Faktory useful.

Reply on news.ycombinator.com