Add storage adapters

[andyrichardson]

About

It would be nice to add support multiple storage mechanisms.

Example

import { createInstance } from 'subscriptionless';
import { DynamoDBPersistence } from 'subscriptionless/dynamodb';

const instance = createInstance({
  schema,
  storage: DynamoDBPersistence({
    dynamodb,
    tableNames: {
      connections: 'my_connections'
    }
  })
});

Notes

Whether this is of any value still remains to be seen.

Drop a comment if you have a use case where something other than DynamoDB would be of use.

[reconbot]

I would like to use ddb but I use a single table design. I can manage to get and return to you a record, but I'd rather implement a few functions that do it my way.

import { createInstance } from 'subscriptionless';

const instance = createInstance({
  schema,
  storage: {
    putSubscription,
    getSubscriptionByConnectionId,
    getConnectionById,
    deleteSomethig,
    // etc
  }
});

[andyrichardson]

@reconbot thanks for the feedback!

Just a heads up, this is going to be a lower priority for now in favor of #3

I use a single table design

I'm not fully aware of your use case but I'd advise against mixing this data with your application data if possible.

The data being persisted is equivalent to runtime memory/RAM and isn't intended to be consumed, modified, or referenced to by other services. I appreciate the advantages of single-table design for highly relational data (i.e. from the business domain), but in this case, the data is best siloed.

I can't think of any cases where co-locating this with other data would be advantageous - and would likely cause more problems than good (risk of cross-contamination, no separation of concerns, slower indexing, maintenance of storage adapter, etc).

That being said, if you can see advantages to going this route, or use-cases where it would be useful - let me know!

[reconbot]

In previous apps I used redis and not ddb. So that's a use case.

I don't mind having other tables in this current app but I'd rather everything stored in a consistent manner. The table isolation is less of a concern to me as most of my data in this particular app is "runtime" and have associated analytics pipelines that would care about the subscriptions and connections. The choices here are highly app specific, which is sort of the point.

I am happy to work on this feature if you're open to it. (Though #8 is a blocker for me right now so it would have my higher priority =p)

[andyrichardson]

@reconbot thanks for offering to get involved!

• This issue isn't a high priority for now unfortunately (even with external contributions). It's something I have looked into but would require fairly intrusive changes
• Add sendMessage handler #8 sounds like you're able to use a local endpoint but let me know if that isn't the case
• Add TTL for subscriptions #6 Isn't a super high priority but shouldn't be too much work (adding ttl attribute to model, default value, and readme instructions) - I would be open to getting that in
• Socket idleness detection #3 is the main priority and is underway. If you know a little bit of AWS/CloudFormation and think you could help with this Support for API Gateway WebSocket (WS) invocation serverless-operations/serverless-step-functions#440 that would be a massive help 💯