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.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.