search

andyrichardson / subscriptionless

GraphQL subscriptions (and more) on serverless infrastructure
MIT License
93 stars 3 forks source link

Add storage adapters #7

Open andyrichardson opened 3 years ago

andyrichardson commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@reconbot thanks for offering to get involved!