Re-implement Cloudtasker Worker controller as a Rack App

[vovimayhem]

After taking a look at how the worker processor is implemented (the part that receives the tasks from Google Cloud Tasks to be processed), I found out there's a ready-to-use controller for rails, but for folks using anything else they'll need to re-implement the controller themselves (as shown in the sinatra example)

I think we can have a single implementation of the controller as a rack application (See "How to survive without a framework in Ruby", for an example), and let the gem users mount it using their corresponding routers (or auto-configure it ourselves, maybe?) - notice how all routers use the same method mount with the same options (at, etc):

Rails example - see documentation at guides:

# at `config/routes.rb`
Rails.application.routes.draw do
  mount Cloudtasker::WorkerController, at: '/cloudtasker'
end

Sinatra Example (can't find a good documentation page):

class MySinatraApp
  mount Cloudtasker::WorkerController, at: '/cloudtasker'
end

Hanami example - see documentation:

Hanami::Router.new do
  mount Cloudtasker::WorkerController, at: '/cloudtasker'
end

[alachaum]

Great idea. It would make the library way more portable.

[vovimayhem]

Started working on it - I currently have a standalone WorkerController implemented using only Rack. But then I came across another idea: Given there's now a standalone rack app, let's have the ability to start just the standalone rack app to process the incoming tasks, and leave the Rails/Hanami/Sinatra/etc app routers alone, separating the web process from the worker process.

In this way, we'll accomplish:

• Being able to scale up/down the project's web & worker processes in our deployments independently.
• Completely eliminate the chance for a surge of worker jobs taking down the web process.
• Reduce - a little bit - the attack surface area on the web process.
• Remove the Rails/Hanami/Sinatra load times from the worker process startup.

You could still be able to manually mount the Rack app inside the Rails/Hanami/Sinatra app routing configuration, if you want to keep the things the way they were before.

[vovimayhem]

(Although we'd still need to load Rails on the workers, if we're going to use ActiveRecord objects in our jobs...)

[alachaum]

@vovimayhem I'm not sure to see the benefit of having a separate process for the controller. It's easier to start a single web app, especially considering that the rack controller needs to have access to the whole code base. So separating the controller in a different process would just duplicate the app in the end, for a single purpose (processing jobs). I don't see any benefit in doing that.

If people want to have a web app processing only jobs they can just deploy their app a second time on a different endpoint.

Let's keep things simple for now.

Note: just in case it's unclear in the README, the "worker" process is only required in development to mimic GCP cloud tasks. In production you don't need the worker process, only the web app process.

[vovimayhem]

I screwed up my changes that day... couldn't rescue anything, so I'll need to do it again (no more git reset --hard for me, thank you). I remember it wasn't that much difficult.

I'm not sure to see the benefit of having a separate process for the controller. It's easier to start a single web app, especially considering that the rack controller needs to have access to the whole code base. So separating the controller in a different process would just duplicate the app in the end, for a single purpose (processing jobs). I don't see any benefit in doing that.

I kinda see some value on this, but I acknowledge it's might not be worth the effort right now. Got it!