Thanks for the tip on RabbitMQ, is this different from using say CRON (for scheduled tasks) or are you talking just processing the large amount of real-time requests, which at this time for me is just first-come-first-serve as far I'm aware.
oh, I never realized that they're both task schedulers with different meanings (I'm not native...^^)
cron is meant to fire off a command at a specific interval or date. RabbitMQ creates a schedule of what should be done in what order.
You generally only use cron for tasks outside of your application context, however. (i.e. creating backups, flushing old temporary files, maybe fetching updated files/data from a third party)
RabbitMQs use-case is much closer to your application: say one of your users wants to export some data. Your frontend application would just add this task to the task schedule and your next worker/cluster node would start processing it as soon as it has resources available.
this decouples the actual web application from what's being done on the server and lets you scale indefinitely, depending on how far you go on that front.
it, however, creates a lot of administrative overhead and is IMO not necessary until your project is already quite large. It might also be possible to scale in another way - it depends entirely on the application you're building.
a shared calendar, for example, wouldn't need this, because there are almost no resource heavy tasks that have to be done.
Comments
oh, I never realized that they're both task schedulers with different meanings (I'm not native...^^)
cron is meant to fire off a command at a specific interval or date. RabbitMQ creates a schedule of what should be done in what order.
You generally only use cron for tasks outside of your application context, however. (i.e. creating backups, flushing old temporary files, maybe fetching updated files/data from a third party)
RabbitMQs use-case is much closer to your application: say one of your users wants to export some data. Your frontend application would just add this task to the task schedule and your next worker/cluster node would start processing it as soon as it has resources available.
this decouples the actual web application from what's being done on the server and lets you scale indefinitely, depending on how far you go on that front.
it, however, creates a lot of administrative overhead and is IMO not necessary until your project is already quite large. It might also be possible to scale in another way - it depends entirely on the application you're building.
a shared calendar, for example, wouldn't need this, because there are almost no resource heavy tasks that have to be done.
Thanks for the explanation/comparison.
I keep hearing about "messaging" but not as in messaging each other but process messaging. When I looked up RabbitMQ I saw messaging.
At any rate thanks a lot for the info/your time.
oh, thanks for pointing that out. we always called it task scheduler at work - but that doesn't seem to be the correct term for it. TIL :)
I think of it as task scheduling, I'm not sure what "messaging" is that RabbitMQ refers to but I've heard of it else where as well.