Skip to content(if available)orjump to list(if available)

A Deep Dive into Solid Queue for Ruby on Rails

nkraft11

I briefly worked at a YC company that was a ruby shop. Their answer to every performance problem was to stick it on a queue. There were, I don’t know, dozens of them. Then they decided they needed to be multi-region, because reasons. But the queues weren’t set up to be multi-region, so they built an entirely new service that’s job was to decide which queue in which region jobs needed to go on. So now you had jobs crisscrossing datacenters and tracking any issue became literally impossible. Massively turned me off to both that company and ruby in general.

throwaway493943

I'm going to be brave (but still use a throwaway) and ask the dumb question - what is wrong with putting things in queues to help with performance problems?

If some endpoint is too slow to return a response to the frontend within a reasonable time, enqueueing it via a worker makes sense to me.

That doesn't cover all performance issues but it handles a lot of them. You should also do things like optimize SQL queries, cache in redis or the db, perhaps run multiple threads within an endpoint, etc. but I don't see anything wrong with specifically having dozens of workers/queues. We have that in my work's Rails app.

Happy to hear how I can do things better if I'm missing something.

teyc

[delayed]

cortesoft

Don't let one company's misuse of a language turn you off the entire thing!

rubyfan

Yeah this is not the fault of ruby. Sounds more like bad choices that could be made with any language or framework.

charcircuit

Culture around a language influences what choices are made.

trevorhinesley

I’ve never felt like “throw everything into a queue” was a mindset within the Ruby community, nor have we done that at my companies. And multi-region is a business decision.

rubyfan

Don’t be silly. Bad choices are made in all sorts of languages and teams - this has nothing to do with language. High pressure situations can lead teams to make choices they don’t always foresee as bad until after they are paying the consequences.

trevorhinesley

Neither sticking everything into a queue nor going multi-region are Ruby’s fault.

teaearlgraycold

Ruby and the age of “I don’t care what type this variable is, it quacks like a duck!” is over and dead. Improvements to type systems have shown there is a better way to do software development.

ch4s3

Maybe, the cycle has happened before and maybe come back around again. Dynamic typing is really nice when most of your data looks like bags of strings. Compilers and tools just don’t add a lot when you’re passing around glorified blobs of stringy json-like stuff. Type gymnastics can eat a lot of time where you could otherwise be shipping something useful.

null

[deleted]