Support multiple subscriptions backends

[georgeboot]

Currently, this package depends on DynamoDB for it's subscription storage.

We should consider allowing multiple storage backends, and probably supply both a Eloquent and DynamoDB out of the box, and let people decide which one to use.

[Adesin-fr]

Thinking about is, and I agree with this. Almost all Laravel projects includes some database, and using the one already setup could remove a bit of complexity in the serverless.yml file.

At first I was thinking that including code to another DB will make the lambda heavier, but in facts we're using the same lambda that serves the application... So it wouldn't change anything !

Should not be that hard to make it an option with a config file. I'll give it a shot as soon I'll have a bit of free time.

[leob]

@Adesin-fr Just hoping it doesn't add too much complexity to the codebase (and to the usage of the package) - we also need to handle deployment, which probably means making serverless.yml more complex (right now, serverless.yml just assumes DynamoDB and automatically deploys the whole thing, which keeps it super simple), unless we'd use a SQL database which we can probably assume is there already ...

So, for me personally this one wouldn't be top priority - DynamoDB is only used here as a piece of "infrastructure", I think I've never even looked at how it works or what's in it - "it just works" ... but, if you can do it in a clean and relatively simple way, then yes by all means, be my guest, definitely not against it :)

Which databases would be a "compelling" alternative for DynamoDB, for this use case - @georgeboot @Adesin-fr ?

[Adesin-fr]

IMHO it won't add so much complexity : DynamoDB is actually a kind of table, with some specific properties that we are not "needing" : it's a key-value kind table, and we just need an equivalent table in any other RDBMS the user already have.

We have to

• implement a "database repo" that will abstract access to the table keeping the connections IDs,
• Add a broadcast config entry to inform the package which "table driver" we want to use.

Nothing to change to serverless.yml : if you add the DDB resource to it, so serverless will create it, if not, then it won't do anything. No added complexity here. If the user has already setup a DB in his app, either MySQL or Postgre or anything else that is eloquent-compatible, then we should just ensure we provide a migration to create this table, and we will use the connection the user has already setup !

The idea behind this is not to replace something that just works with something else because "we are dev, so why not", but to replace a service we have to pay for with another service we already paid for : on my use-cases, 100% of my projects already have a RDS Mysql that I pay even when not used, so not having to pay an extra (a few cents, ok ...) for DynamoDB is a win ;)

But you are also right, this one is not a top priority, I prefer to fix bugs first !

[leob]

IMHO it won't add so much complexity : DynamoDB is actually a kind of table, with some specific properties that we are not "needing" : it's a key-value kind table, and we just need an equivalent table in any other RDBMS the user already have.

We have to

• implement a "database repo" that will abstract access to the table keeping the connections IDs,
• Add a broadcast config entry to inform the package which "table driver" we want to use.

Nothing to change to serverless.yml : if you add the DDB resource to it, so serverless will create it, if not, then it won't do anything. No added complexity here. If the user has already setup a DB in his app, either MySQL or Postgre or anything else that is eloquent-compatible, then we should just ensure we provide a migration to create this table, and we will use the connection the user has already setup !

The idea behind this is not to replace something that just works with something else because "we are dev, so why not", but to replace a service we have to pay for with another service we already paid for : on my use-cases, 100% of my projects already have a RDS Mysql that I pay even when not used, so not having to pay an extra (a few cents, ok ...) for DynamoDB is a win ;)

But you are also right, this one is not a top priority, I prefer to fix bugs first !

@Adesin-fr Okay, yes that makes sense:

"The idea behind this is not to replace something that just works with something else because "we are dev, so why not", but to replace a service we have to pay for with another service we already paid for"

I think you have a point there ... let's keep this issue open then, and we (or you) can work on it when we have time!