Adopting patterns in the official Slack bolt-js library

[JadedEvan]

Hello all! Thank for reading!

The reason I've opened this issue is to start a discussion about implementing types in this Rust library in a manner similar to the official bolt-js library maintained by Slack. Over the course of the last few months I've had the opportunity to get hands-on creating a fully-fledged slackbot for my organization. For this work I ended up creating a Typescript implementation based off the Bolt JS library. This gave me a lot of insight into the mechanics of building the app and what is valuable in these "off the shelf" libraries.

Goal 1 - full type implementation

As an example the current slack-rust library has partial or incomplete implementations of certain event types. As an example I'd ask to compare the AppMention event.

Below is the Rust implementation

    /// Subscribe to only the message events that mention your app or bot
    AppMention {
        channel: String,
        event_ts: String,
        text: String,
        thread_ts: Option<String>,
        ts: String,
        user: String,
    },

And the Typescript version from Slack

export interface AppMentionEvent {
  type: 'app_mention';
  subtype?: string;
  bot_id?: string;
  bot_profile?: BotProfile;
  username: string;
  team?: string;
  user?: string;
  text: string;
  attachments?: MessageAttachment[];
  blocks?: (KnownBlock | Block)[];
  edited?: {
    user: string;
    ts: string;
  };
  ts: string;
  channel: string;
  event_ts: string;
  thread_ts?: string;
}

You can see that there is a lot more optional information present in the Typescript implementation. I find this to be extremely valuable, having these attributes explicitly defined. It was massively helpful to be able to reference the full data structure in the TS library when making my own implementation.

I would suggest that for the slack-rust library we make sure that full structures are implemented for all API interactions (events, users, apps, etc) - as I don't believe they are currently complete compared to the BoltJS offering.

Goal 2 - Separating types from interaction

One thing I appreciated about the BoltJS library is that they separate the types from the API interactions / implementations. As a result, you get a directory (bolt-js/src/types) that gives you access to the types only. While the "off the shelf" library does give you nice stuff like Websocket listeners, it does a good job of separating the types from the application code.

First I would make a suggestion that this slack-rust library follow suit. As you can see in the current slack-rust/src/users directory this is a mix of API implementations (deleting photos) and concrete types (ex: UserProfile). I don't have a map of what structs and enums would move, but I think it would be helpful to get all of the API structures into a more organized directly.

As a second goal, I think it might be nice to think about separating the types into their own library and keeping the application behavior in another separate library. It seems to me now that this crate becomes quite heavy, as it includes a lot of other tools (for things like websocket servers). It might be preferrable to separate the two so that you can get the types, or the application, or both depending on your use case. Right now they seem pretty strongly coupled.

Next Steps

I'd be happy to put together a PoC (Proof Of Concept) for what this might look like, as I realize it's a bit hard to simply describe these suggestions. I felt that it might be valuable to share these insights with my experience with the TS version since I'm quite fond of the rust ecosystem and feel much more confident making tools in this language instead of TS.

Thanks for hearing me out!