views:

40

answers:

2

I'm having an implementation challenge at the moment, it basically consists of two different rails apps.

One rails app (app A) just provides a response in JSON, a record in this case for the nutrition data for one particular food ingredient.

The other app (app B) also Rails provides a front-end for users to view ingredients and match them up with search results provided by app A.

The reason we did this is because we want to eventually make app A into a publicly accessible API for nutrition data, so we figured to take the load off the web App B we could make it stand alone.

I guess I wanted to get the thoughts of you guys on generally how you would handle two systems that need to be tightly integrated in this way.

+1  A: 

I would create a new Rails 3 application because Rails 3 is tightly integrated with Rack. Rack allows us to insert various adapters in the request processing chain. Those can help us to differentiate between requests of various kinds (standard requests, API requests).

For the application A I would use something lightweight, like Sinatra (or even my own Rack adapter built from scratch). This is due to the fact that API generally will not use any extra super features of Rails and its magic.

So, strictly speaking, I will create only one application (the application B) on Rails 3 that will have a kind of submodule for the API processing. Thus, they will be binded with each other.

floatless
+1  A: 

Whether App B is an internal application or external, it's the responsibility of App A to expose the nutrition data. That's something you don't want to duplicate.

The internal App B should use the same mechanism as external applications to access this exposed function. Think of App B as the first client that uses the API.

Kwebble