Refactor the Enqueue API

[xescugc]

This issue is more of a question on which way is the better to approach the following issue.

I've started using this lib to implement a web service using Resque just in GO. With the Enqueue API works fine but there is a problem with it, this library was thought at the beginning to implement Workers that consume Resque, so that the code that is running this lib is a worker, not a web service.

This presents the following issue, if you have a web service that enqueues jobs (ex: Send Emails) when you run this:

From the documentation

package main

import (
        "fmt"

        "github.com/benmanns/goworker"
)

func main() {
        err := goworker.Enqueue(&goworker.Job{
                Queue: "myqueue",
                Payload: goworker.Payload{
                        Class: "MyClass",
                        Args:  []interface{}{"hi", "there"},
                },
        })
        fmt.Println(err)
}

$> go run enqueue.go

This returns an error saying that you must specify at least one queue, of course this should not happen because this code is not registering a worker, just pushing data to Redis.

$> go run enqueue.go -queues somequeue

This is the way it works now, the queue in which the Job is going to be pushed is the myqueue specified on the code, not the somequeue of the flags.

For this problem i have two possible solutions:

• Separate the API for Pushing data to Resque (Enqueue) and the API for consuming it (Workers) so when you import it, you specify which one you want.

• Delay the validations until they are used (lazy), when a Worker is created, then validate the queues, not before.

Which is of them ( or others ) do you prefer ? I ask this because sending a PR with a big change like that should be consulted before, that's what I think hehe.

Edited: Of course from this 2 solutions the first one changes the API so on back compatibility, which is important 😢 .