For further actions, you may consider blocking this person and/or reporting abuse
Read next
Top Observability Best Practices for Microservices
Wallace Freitas -
What 10,000 Hours of Coding Taught Me: Don't Ship Fast
Sotiris Kourouklis -
Consuming HTTP Streams in PHP with Symfony HTTP Client and Ollama API
Roberto B. -
Navigating the New Grad/Junior SWE Job Hunt: Landing Interviews
Gabrielle Niamat -
Top comments (4)
I usually break is apart like this
HTTP requests are for when I need this info right now. If a user makes a request we want to fulfill it right now and not wait. So that would be a case of making an HTTP request to our micro services.
Messages (Typically I like queues, like AWS SQS. I have a post about it) is for async stuff. If a user uploads an image and you want to resize it that probably can wait a second. So you might upload the full size then pass a message to your image service telling it you want this resized.
In short anything synchronous you want HTTP requests. Anything asynchronous you can use message passing.
We started down this path, then found that consumers of asynchronous contracts were not happy with the coupling to specific queue technologies, so our services now wrap any queue and present a single API technology (HTTP). We are also looking at webhooks for returning responses rather than direct queue access, to retain the single low coupling technology approach, although all our async services are fire-and-forget ATM. YMMV :)
Yeah it's nice to be able to still access things via HTTP even if it just enqueues something. But I at the architectural level that's how I think of it. Hooks are great too, since you can use queues behind the scenes for those as well.
We might have something that puts an event to call a hook in a queue. Then the hook service reads that and makes a post request to the consumer.
I don't think it's necessarily an either/or. Some services will do better with HTTP/gRPC and others with messaging. It's about picking the right tool for the job.
Even between HTTP and gRPC it isn't one size fits all. For our high throughput part of our application we'll use gRPC due to the decreased overhead. But HTTP is easier to read and debug, so that would be the default choice for our other direct-call scenarios.
And some services benefit from messaging but there is also additional complexity there. Does your system behave if the message is delivered twice? If the messaging service is a deliver once queue, what happens when the service dies after getting the message?
You really have to think about which services benefit from which communication method and what the tradeoffs are. Obviously HTTP/gRPC suffer from some of their own pitfalls.
Unless your app is very simple, in which case microservices probably are more of a hindrance, you will likely need both.