Here is something I have been pondering about:
I have one main app and one services (two Rails applications deployed to different domains, I am extracting the service into its own app), and I want to display information from the service on a page in the main app. Surely this is becoming more and more common nowadays. I am thinking this can be conceptually done with "widgets" that the service provides, that are embedded in the main app. However I am not sure what the best implementation would be. What I considered:
1) Service exposes pure API, widgets (JS/templates/css) live in the main app.
+ Pretty standard approach
+ UI is consistent as all widgets live in the main app
- Have to deal with CORS on older browsers/IE
- widgets are coupled to the API but live in a diff app, susceptible to break if API changes
2) Widgets live in the main app, and rendered as a standard rails partial, after main app call the service API.
+ well… simpler
- locks the whole process/thread for the duration of the main->service request
- Same problem with widgets coupled to the API
3) Widgets live in the service app and embedded via an iframe.
+ Widgets/templates change together with API
+ good isolation b/w main app and the service, can't break main app, no js version conflicts
- UI may (and probably will) drift to inconsistency
- seems to be limiting the interaction on the main site (can the main page page listen to events from the iframe?)
+ possibly the most flexible option
- possibly the most complex option? How much more the widget code will have to be comparing to option 1?
My goal is to optimize for the team scalability/isolation, where the service can be done by a different team (potentially outsourced) with a different deployment schedule independent of the main app (well, this is an aspiration :) This approach will be repeated for other services to be extracted.
What I am looking for is some words of wisdom from peeps who have done it, what worked, what didn't, best practices, etc...
Sent with Sparrow