Extend support for other apis, analogous to python-sunlight

[kaitlin]

Ruby-sunlight needs to support the other Sunlight APIs, including

-Influence Explorer
-Capitol Words
-Party Time
-Open States

Additionally, ruby-sunlight should incorporate changes for the new Congress V3 API. There are ruby gems that have this code already though, so maybe just direct users to that gem? Gem: http://rubygems.org/gems/congress

For reference, here is python-sunlight

[sunnyrjuneja]

Any ideas on you want to move forward on this issue? Currently, the Ruby builds a class for every general API function whereas the Python just has a generic class for each API.

[kaitlin]

Hmm, class per API makes more sense to me, but I don't have strong feelings about it. @konklone might have a more specific recommendation as he's our resident Rubyist.

[konklone]

11 months ago, I did some uncompleted work on adapting to the new Congress API, it's on the new_congress_api branch.

However, that congress gem is powered by codeforamerica/congress, which is actively maintained and much more well-tested.

Personally, I'm not as convinced a ruby-sunlight library even needs to exist that ties our APIs together, but if we want to do that, I'd want to piggyback on the good work over at the congress gem, in a way that directly supports that library (and doesn't use it as an invisible implementation detail).

To do that, I'd recommend we just make the congress gem a dependency, and update our documentation to say that users should just expect that gem's Congress namespace to be loaded and to follow that gem's documentation.

[konklone]

Also, @whatasunnyday, I note that the codeforamerica/congress gem doesn't have any geocoding support - if you still have the energy, one nice and impactful PR would be to add geocoding to that library via geocoder.

[sunnyrjuneja]

Cool, that makes total sense. I'm totally down to add support to Geocoding to the congress gem.

[sunnyrjuneja]

@konklone Just did it. I have no idea if you're a contributor but feel free to check out the PR and give some feedback.

[sunnyrjuneja]

@konklone how do you feel about creating standalone gems for each api and requiring them as dependencies?

I found https://github.com/pengwynn/transparency-data but I couldn't get any of the examples to compile. I would be happy to rewrite something for influence explorer and maybe a few of the other APIs and wrap them in sunlight-ruby.

[konklone]

Yeah, our Transparency Data (now Influence Explorer) API has changed a lot in the last 4 years, I'm not surprised.

I think either way (extending ruby-sunlight to talk to our APIs, or creating standalone gems) is fine. There's not a lot of use for a gem that only bundles other gems together, though. The congress gem emerged, and gets maintained, because people are using it in practice in a bunch of projects. I'd rather only spend time on a Ruby gem that's going to definitely see some use.

[sunnyrjuneja]

@konklone good point. have you heard anything about a burning need for any of the APIs to be wrapped?

[konklone]

I'm not sure, but I think if there was any API that could use a Ruby library, it's our Open States API. It's very widely used. Unfortunately, they're in the middle of a transition to a new API, so it's not very good timing.

[sunnyrjuneja]

Is there anywhere I can view the proposed changes?

[sunnyrjuneja]

By the way, I sent you an email if you don't mind responding to that.

[konklone]

The main discussion is here: https://groups.google.com/forum/#!topic/fifty-state-project/u8vidiJUH1k

The new API is up, it's documented here. I'd post to the list I linked to above and offer to write a little Ruby gem, so that they know what you're doing.

[sunnyrjuneja]

Cool, thanks!