3 ms·

This is standard practice on monolithic apps. It is effectively an N-tier architecture. On Rails it is very expected that you would deploy the same codebase to

This is standard practice on monolithic apps. It is effectively an N-tier architecture. On Rails it is very expected that you would deploy the same codebase to two tiers (web and worker) and simply run rails s in one and sidekiq in the other.

heipei 4y ago
We're doing this with our monolithic Node.js / Express application as well, but I wasn't aware that it's a common pattern. For us having a monolithic app greatly simplifies development, deployment, updating dependencies, shared code, etc. Just having a single set of third-party dependencies to update makes things so much easier.
- lawrjone 4y ago
  It’s ‘standard practice’ for many frameworks like Rails which encourage the pattern via a separate deployment of the async worker tier. But outside of these frameworks, you won’t often see it. And especially in languages like Go which tend to avoid opinionated frameworks it’s common not to see a split like this, even when it might be really beneficial. As with most programming concepts, standard practice varies a lot depending on the tools you use. It’s why I thought this post was worth writing, in that there are many people who haven’t run Rails/etc frameworks before and may not have considered this approach!
- Rapzid 4y ago
  It's so common Heroku has worker dynos and cron support via the scheduler add-on.
KyeRussell 4y ago
Ditto in Django + Celery
- slig 4y ago
  Anyone using a more modern/lightweight alternative to Celery?
  - jerrygenser 4y ago
    Yes, dramatiq is quite good, but I ditched it for something even more lightweight -- pubsub subscribers via push notification so workers are web workers responding to http requests that might take up to 10 minutes
    - slig 4y ago
      That's a very interesting approach. Do you have anything written about it or any public repo? Thanks!
  - smaccona 4y ago
    We use RQ[0], it has Redis as a dependency. It’s pretty straightforward and we’re very happy with it. If you are using Django you may want to look at Django RQ[1] as well. RQ has built in scheduling capabilities these days, but historically it did not so we used (and still use) RQ Scheduler[2] which I think still has some advantages over the built in stuff. [0] https://python-rq.org/ https://python-rq.org/ [1] https://github.com/rq/django-rq https://github.com/rq/django-rq [2] https://github.com/rq/rq-scheduler https://github.com/rq/rq-scheduler
    - slig 4y ago
      Thanks, will check it out!
  - ibejoeb 4y ago
    If you're using PostgreSQL, then django-postgres-queue: https://github.com/gavinwahl/django-postgres-queue https://github.com/gavinwahl/django-postgres-queue procrastinate: https://github.com/procrastinate-org/procrastinate/ https://github.com/procrastinate-org/procrastinate/
    - 4y ago
fideloper 4y ago
ditto Laravel (PHP)

heipei 4y ago

We're doing this with our monolithic Node.js / Express application as well, but I wasn't aware that it's a common pattern. For us having a monolithic app greatly simplifies development, deployment, updating dependencies, shared code, etc. Just having a single set of third-party dependencies to update makes things so much easier.

lawrjone 4y ago
It’s ‘standard practice’ for many frameworks like Rails which encourage the pattern via a separate deployment of the async worker tier. But outside of these frameworks, you won’t often see it. And especially in languages like Go which tend to avoid opinionated frameworks it’s common not to see a split like this, even when it might be really beneficial. As with most programming concepts, standard practice varies a lot depending on the tools you use. It’s why I thought this post was worth writing, in that there are many people who haven’t run Rails/etc frameworks before and may not have considered this approach!
Rapzid 4y ago
It's so common Heroku has worker dynos and cron support via the scheduler add-on.

KyeRussell 4y ago

Ditto in Django + Celery

slig 4y ago
Anyone using a more modern/lightweight alternative to Celery?
- jerrygenser 4y ago
  Yes, dramatiq is quite good, but I ditched it for something even more lightweight -- pubsub subscribers via push notification so workers are web workers responding to http requests that might take up to 10 minutes
  - slig 4y ago
    That's a very interesting approach. Do you have anything written about it or any public repo? Thanks!
- smaccona 4y ago
  We use RQ[0], it has Redis as a dependency. It’s pretty straightforward and we’re very happy with it. If you are using Django you may want to look at Django RQ[1] as well. RQ has built in scheduling capabilities these days, but historically it did not so we used (and still use) RQ Scheduler[2] which I think still has some advantages over the built in stuff. [0] https://python-rq.org/ https://python-rq.org/ [1] https://github.com/rq/django-rq https://github.com/rq/django-rq [2] https://github.com/rq/rq-scheduler https://github.com/rq/rq-scheduler
  - slig 4y ago
    Thanks, will check it out!
- ibejoeb 4y ago
  If you're using PostgreSQL, then django-postgres-queue: https://github.com/gavinwahl/django-postgres-queue https://github.com/gavinwahl/django-postgres-queue procrastinate: https://github.com/procrastinate-org/procrastinate/ https://github.com/procrastinate-org/procrastinate/
  - 4y ago

fideloper 4y ago

ditto Laravel (PHP)