SlackStore (replacement for DataStore)

Description

For reasons discussed in #330, there is a need to provide a better alternative to the SlackDataStore abstraction. This issue is meant to help specify a new solution and to scope the first implementation.

1. The API for storing and fetching data must be asynchronous. Ideally, this means both with callbacks and with Promises. (#246).

2. The API must allow processing of incoming events from the RtmClient of the @slack/client package AND from the SlackEventAdapterof the @slack/events-api package.

   • De-duplication of incoming events is not guaranteed if sourced from an RtmClient, but must be guaranteed if sourced from a SlackEventAdapter. It must be very clear that de-duplication isn’t being handled, possible even an error, if one store is connected to more than one RtmClient.

3. The API for storing and fetching data should be optimized for both relational backends and key-value backends. This might mean that there are two separate interfaces that a backend can choose between implementing.

4. The API should make it trivial to update the data using outgoing requests. For example, the WebClient can be used to call the users.list method, and it should be trivial to update the data in the store with the results.

Requirements (place an x in each of the [ ])

• I’ve read and understood the Contributing guidelines and have done my best effort to follow them.
• I’ve read and agree to the Code of Conduct.
• I’ve searched for any related issues and avoided creating a duplicate issue.

[aoberoi]

found a neat library that has the potential to power part of this solution: https://github.com/lukechilds/keyv

[clavin]

Ah, I guess it’s just me blinding myself. I was (and still am) under the illusion that Promises have been widely well-received and commonplace; I didn’t realize that the wider Node/JS community might not really be interested/comfortable. In that case, I say go all out with a duplex asynchronicity implementation (both promises and callbacks) to make happy as many people as possible.

As an added benefit, I can see that having both means:

• Attraction to well-rounded Node/JS devs who are comfortable with the latest technology, including promises
  • i.e. easy to work with in async-await environments
• Attraction to newer JS devs who are just barely grasping the ropes of asynchronicity
  • And then there’s also people who live in a world without the graciousness of promises on purpose (maybe due to compatibility with past versions of node)

This is only a good thing, however, if your target audience for the SDK includes not-so-versed/past-dwelling developers.

Also, I was a little ambiguous (my fault) in my comment; I’ve continued to feel that the public interaction from SDK-consumer (a developer) to SlackStore should totally be versatile in order to adapt to all types of developers. Anyone who wants to use the SDK overall should be able to do so with ease, and having both promises and callbacks is a pretty amazing way of making the SDK easy to use for all.

I was more-so caught up in the implementation details, wherein I felt that it would be weird having a system where the internal back-end for handling data storage has both promises and callbacks. That is, making available to those who implement storage back-ends, i.e. Redis or in-memory or file system or SQL, both implementations of asynchronicity would be a weird choice. A bit of a niche complaint, though. I suppose it’s better to support both for internal actions too simply for widening the range of support for the SDK.

All in all, as long as the details of implementation are figured out, I’m happy. Regardless of what they are, figuring out the details paves the way for actually implementing those details, leading to an amazing, new SDK ✨😎. Can’t wait to see what’s in store 👍.