Nit: the application the author describe doesn't even publish the request using RabbitMQ, as far as I can tell—they publish the request with a simple HTTP request. They use RabbitMQ solely for scheduling the "Check if this task is done yet" job every ~5 minutes. I haven't used RabbitMQ myself, but it does sound like kind of like a square peg / round hole situation to me.
I've built systems similar to this dozens of times and what they're doing makes no sense. Use a database table to store the state of a given job and query it. Super fast, efficient and you're not hiding state in what should be an ephemeral part of your infrastructure.
The MQ is great for scheduling jobs, passing data between different parts of a given process and generally detaching systems. However fast it is not, unless you're using something like Zero MQ for slow IPC.
I was also surprised by that but there may be some slightly unusual background reason for that that simply doesn't get mentioned. Superficially it sounds like the author should just... do the HTTP request? Since they're waiting for the response anyway
I'm not sure the exact idea here because they said something about retrieving PDF and JSON data, but a big reason for not doing this is normally that some calculation or whatever takes a lot longer than you want a HTTP request to take. So you effectively push the work off, and then the user comes back at a later time and something has been processed and they can see the result.
Almost twenty years ago, I was on a team that built a bunch of health care apps where we had significant, robust mainframe business systems that we needed to get in front of both internal staff, external providers, and the public. So yes, those systems definitely used a whole lot of messaging and in my career since I saw repeats of those patterns not only in that industry, but also financial services, telco, and lots of other places I stopped along the way. Anyplace you’ve got hulking business systems with lots of rules, it’s common to have messaging in between there and the web, and for various distributed applications to talk to each other.
nightpool|3 years ago
radicalbyte|3 years ago
The MQ is great for scheduling jobs, passing data between different parts of a given process and generally detaching systems. However fast it is not, unless you're using something like Zero MQ for slow IPC.
jhh|3 years ago
physicsguy|3 years ago
poulsbohemian|3 years ago