Move Bundler API to Rubygems.org

[maclover7]

PR to combine Bundler API's Sinatra app with Rubygems.org's Rails app.

cc @indirect

TODO:

• Import bundler-api code
• Rails-ify
• Remove duplicate tasks?
• Figure out subdomain/routing stuff --> use the "api/v1/dependencies" endpoint
• Add caching
• Provision memcached in production (@dwradcliffe)
• Make sure tests are passing
• performance/load testing
• 🎉

[dwradcliffe]

Let's get rid of librato before doing this.

[maclover7]

@dwradcliffe What metrics service are we moving to instead of Librato?

[segiddins]

@maclover7 maybe a subtree merge would be better, so we can preserve history?

[indirect]

@segiddins since I expect this PR to reimplement the API as a rails controller before it's merged, I think the history probably isn't worth it in this particular case. Good idea, though.

On Wed, May 27, 2015 at 9:36 PM, Samuel E. Giddins
notifications@github.com wrote:

@maclover7 maybe a subtree merge would be better, so we can preserve history?

Reply to this email directly or view it on GitHub:
#966 (comment)

[arthurnn]

Agree with @indirect . I dont think we should port the code honestly.
We should rewrite it in a Rails controller, from scratch, having the new api as base line.
I think old bundler-api server can still run for the old api, and rubygems.org will only have the new API.

[maclover7]

What domain/sub domain will we be running the API on? bundler.rubygems.org? We have to keep in mind that v2 (new index) API will be coming out soon...

[bf4]

any reason not to do this as an engine/rack app in another repo and mount it?

[indirect]

@B4F because it would make the rg.org depend on more stacks to run (Sinatra/sequel as well as Rails/AR). This isn't super important, but it's a nice to have as we transition away from the API being the main index that people use.

[maclover7]

@indirect @qrush Does the current Bundler API and the Rubygems.org API overlap at all with their functionality? (I'm not very familiar with the codebase)

[indirect]

@maclover7 nope, no overlap. The Bundler API only provides dependencies, and the current Rubygems API has no equivalent.

[maclover7]

Gotcha. Was just wondering if everything needed to be written from scratch, or if there was any starting point. I know @dwradcliffe said we would be moving off of Librato -- what stats logger are we moving to?

[dwradcliffe]

@maclover7 We're moving everything to datadog/statsd. I think @andremedeiros is working on migrating it.

[maclover7]

Got done a lot of work with @indirect, we Rails-ified the web process. Only thing left to do is to integrate Memcached (ping @dwradcliffe).

[qrush]

Can we get this all in a model? DependencyResolver or something. This is a ton of logic for a controller.

[maclover7]

So, we would call DependencyResolver.new(gem_names) ?

[qrush]

Sounds good. And then you can to_json or to_marshal it in the respond_to block.

[qrush]

Can we port over the bundler-api tests too?

[maclover7]

Do we want to port those over from RSpec?

[qrush]

Without a doubt. It should be pretty straightforward.

[maclover7]

@indirect Removed the memcached travis service commit. Rebased on master, and now Github is saying there are merge conflicts (which there aren't -- git locally on my machine says I'm up to date). Travis doesn't create a build job unless Github says there are no merge conflicts

[dwradcliffe]

@maclover7 merge conflict is probably in the routes

[segiddins]

@maclover7 any interest in revisiting this?

[maclover7]

I'll take a look at this tonight, and bring this up to speed. :)

[maclover7]

Uh, what? Rebasing appears to be have closed my PR...?