Hacker News new | ask | show | jobs
by ingonealan3 1397 days ago
Am I missing something about modern backend development, or does this article assume that all backends are built using a microservice architecture (and this implies some form of inter-service communication, for which message queues are a good fit)?

To put it in another way: if I were to build an (fairly simple, monolithic) API, would I automatically benefit from using a queue? If yes, how exactly would a queue be used, and in what way would it bring a benefit?
2 comments
perlgeek 1397 days ago
> if I were to build an (fairly simple, monolithic) API, would I automatically benefit from using a queue?

Queues basically serve as a decoupling layer. If you need one, you'd benefit from one.

Example one: you put incoming requests into a queue. If latency isn't a big concern, that means that your service can go down / be restarted for a moment while the queue buffers all the incoming requests.

Example two: you write a HTTP API for an interactive web application. Fast response times are important, so you do only what you absolutely must inside the request handler, and everything else that can be done later (like sending mails) is put into a queue, and can be dealt with later either by another component, or by your service running "queue worker" mode instead of in "http responder" mode.

If your services is just reading data from a DB and handing it back to the user, you usually don't benefit from a queue. But most apps tend to become more complicated with time...

link
thinkingkong 1397 days ago
A monolithic application can still have queues; there's no need for them to be coupled with a microservices architecture. They at least afford you a 'fire and forget' decoupling in parts of your code that might be nice. For example, take this action and fire this event. Then in another part of your application you can subscribe to events.

They aren't _queues_ per say but they have a lot of the same DX. Depending on your runtime environment as well, you might benefit from splitting side-effect jobs from your API request/response cycle. That way you can still respond quickly while enqueueing work (locally) all still within a monolith.

link