Extract storage, api and web layers into pluggable components

[dblock]

From #3, we probably want:

• slack-ruby-bot-service: just the service parts that starts/stops/restarts/manages a set of teams and bots
• slack-ruby-bot-store: a set of models that give a team storage
• slack-ruby-bot-api: an API for slack button integration and teams
• slack-ruby-bot-web: a Web UI and API to register teams

[m5rk]

I recently integrated the concepts from this gem into an existing Rails app. I appreciate your work, @dblock, and all the help you've given me along the way. I was unable to use this gem as-is because I did not want to introduce MongoDB as a dependency.

Here's what I did instead:

1. Created Rails.root.join('lib', 'slack-ruby-bot-server') and copied the corresponding service.rb and server.rb from this repository into that directory.
2. Created Rails.root.join('lib', 'slack-ruby-bot-server', 'ext', 'slack-ruby-client') and copied the corresponding file from this repository into that directory.
3. Modified service.rb to remove the mongoid-specific rescue
4. Added a rake task to run the service.
5. Modified SlackRubyBotService.start! to loop so the rake task that runs it doesn't immediately exit.
6. Created my own Team model to match the "interface" expected by the server/service classes.

Next up for me:

1. Make the service check for new teams to serve.
2. Make the service check for teams to stop serving.

For both of these, I don't want the code where those activities take place to interact with the service instance since they are different processes (for me, separate dynos in separate process types on heroku).

I'd love to find a way to contribute my work to this gem. I tend to think reducing its assumptions about storage is a key first step, which is at least part of what this issue is about.

[dblock]

+1 on reducing the assumptions about storage - I think the first step would be to extract a storage interface

[p1Machado]

I am starting some work to extract the storage interface for use in a private project.

It will be available in my repositories, would appretiate some feedback later.

[p1Machado]

I am looking to SlackRubyBotServer::App and considering what should or should not continue in this class.
Some methods I think that should be removed, because they belong to storage processing, and others related to database, but not exclusively.

I think some methods should be removed from the App class:
silence_loggers!
check_mongodb_provider!
create_indexes!

Others, even being related to database, have something to do with SlackRubyBotServer, like:
check_database!
mark_teams_active!
update_team_name_and_id!
migrate_from_single_team!
purge_inactive_teams!

Do you have some considerations in this matter?

[dblock]

Take a look at #38, build on top of that.