Extract non-Rails bits into okcomputer-core

[pbyrne]

Following up on #85 (and by extension #83), I think it'd be straightforward to extract the guts of the gem into something like okcomputer-core, which could be used by others to build OK Computer for whichever tool they're using, be it Rack or Grape or Sinatra or what-have-you. Maybe even a command-line app?

Related to this effort would be a few questions:

• Should we deprecate okcomputer and build okcomputer-rails to make it clear that this is merely the Rails implementation of the idea?
  • One risk to this plan would be getting everybody to use the newly named gem.
• Already discussed in Splitting out okcomputer-contrib #56, we could split out the more esoteric checks into okcomputer-contrib which contains all the optional checks for things like Resque or Sidekiq or whatnot.
• Is it reasonable for okcomputer-core to enable the DB check by default? Probably not, since ActiveRecord can no longer be presumed. Or do we alter altogether how the default checks are set-up, leaving that decision to the gem which integrates it into their app server?

---

Once okcomputer-core is available, ping @darbyfrey so he can use that rather than this gem in https://github.com/bellycard/okcomputer-grape.

[darbyfrey]

I'll add in my 2 cents FWIW:

• It can be real tricky to get an existing user base to switch over to a different gem name. I have no context on the size of the okcomputer user base, but that might be something to consider. I also think that in the Ruby community, it's generally assumed you're using Rails, so if okcomputer is what okcomputer-rails would be, people probably wouldn't be confused. You could still extract the core to okcomputer-core and okcomputer would be the Rails API.
• I actually like that the main gem contains all the esoteric checks. Then I don't have to think about which gems I need to pull in for my checks. I'm also using many of those checks anyway, so it's no different for me.
• The DB check by default is still a good idea. Any thing you can do to automate the setup for the 90% use case is worth it as long as it degrades gracefully. For example, you could just do a defined?(ActiveRecord) to see if AR is present and if not, skip the check.

[pbyrne]

It can be real tricky to get an existing user base to switch over to a different gem name.

Agreed. This is my biggest concern about maybe renaming the gem. There was some back-channel conversation around this in Slack, but I'll let the people who suggested it handle convincing us here. :)

I actually like that the main gem contains all the esoteric checks. Then I don't have to think about which gems I need to pull in for my checks.

That's a good point. Keeping them bundled together makes things easier. Even if we do split out okcomputer-contrib, we could still include it as a dependency in okcomputer. Or maybe we never split it out.

The DB check by default is still a good idea.

To be clear, I think in okcomputer a default ActiveRecord DB check makes sense, since few Rails apps won't have a DB of any kind. But I think we could get away with an okcomputer-core only registering the default up-check, allowing each implementation to specify their own defaults on top of that.

[anfleene]

I'm still in favor of an okcomputer-core gem that doesn't contain anything rails specific. I'm not sure we need a contrib gem yet. I like the idea of restructuring how you load checks so that you can pick and choose them based on require or even based on included constants. I think we can put off the okcomputer-rails discussion for awhile and keep using okcomputer proper as the rails gem for the time being. But making this abstraction sets us up nicely for the future if we decide to pull that trigger.

@pbyrne If I remember our conversation correctly this was sort of what we had already agreed on right?

[johnnyshields]

This looks like a dupe with #56... can we decide on an approach and close one of the issues? My vote is for okcomputer and okcomputer-contrib