RFC: split Web API client and RTM client into separate repos and gems

[jmanian]

With the introduction of the Events API a couple years ago RTM is no longer the only way to build a Slack app — many apps use the Web API without using RTM (and it's also possible to use RTM without using the Web API, but I imagine this is less common). So bundling the Web client together with the RTM client doesn't make much sense any more.

The shared code is minimal, so separating them should not be difficult. I think there are two reasonable approaches:

1. Separate the Web API and the shared code into a new lower-level gem, e.g. slack-ruby-web-client.
   1. This gem would remain as slack-ruby-client or be renamed to slack-ruby-rtm-client and it would depend on slack-ruby-web-client.
   2. slack-ruby-bot would continue to depend on this gem.
   3. Someone who needs only Web can get it with slack-ruby-web-client.
   4. Someone who needs RTM would be forced to get both through this gem.
2. Split this gem into two separate gems which don't depend on each other: slack-ruby-web-client and slack-ruby-rtm-client.
   1. With this approach I'm not sure what would happen to the shared code. Either:
      1. put the shared code in yet another gem, e.g. slack-ruby-lib, for both gems to depend on
      2. duplicate the shared code in both gems? :x:
   2. slack-ruby-bot would depend on both of the new gems.
   3. Someone who needs only Web can get it with slack-ruby-web-client.
   4. Someone who needs only RTM can get it with slack-ruby-rtm-client.

I prefer option 1. I'm not totally sure the protocol for splitting up gems. Maybe something like this:

1. Fork this repo into slack-ruby-web-client.
2. In slack-ruby-web-client:
   1. Remove all the RTM code, leaving only the Web code and shared code
   2. Restart the version number and changelog — publish a new gem.
   3. Update README to clarify the new situation and the history.
3. In slack-ruby-client (this repo):
   1. Remove all the code that is now present in slack-ruby-web-client.
   2. Add a dependency to slack-ruby-web-client.
   3. Add an entry to the changelog reflecting the change.
   4. Update README to clarify the new situation and the history.

[dblock]

I've always wondered whether that's really worth it. What are the dependencies we're forcing on the users from the RTM implementation by keeping these together? Is it just extra code being carried around?

The RTM api definitely depends on the web api, so I think (2) is a no go unless we're duplicating code, and I think that's a bad idea. So I'd vote for 1.

If you want to give it a try you could fork this now and make 2 gems. Once those look good we can move them into the slack-ruby org and deprecate this one.

[jmanian]

I also wonder if it's worth it ... 🤷‍♂️ Maybe I'll try it if I have time.

I think you're right that it's basically just extra code being carried around, so it's not a huge deal. There are a few other benefits of splitting them, like having separate change logs and everything else that comes with having separate repos. But again, not a huge deal.

[pusewicz]

If you want to give it a try you could fork this now and make 2 gems.

We can also simply build 2 gems out of the same codebase. No need to split the repo in any way.

[dblock]

If you want to give it a try you could fork this now and make 2 gems.

We can also simply build 2 gems out of the same codebase. No need to split the repo in any way.

That sounds lazy :) For the CLI I think we definitely want a separate project.