Best design for a Facebook application that runs on both JSP & Drupal (same-origin policy issues)

Events happening in the community are now at Drupal community events on www.drupal.org.
EvanDonovan's picture

My organization (TechMission) currently has a live Facebook app on facebook.christianvolunteering.org, and a Drupal install at www.urbanministry.org. The Facebook app is coded in JSP, but runs off the Drupal database. (To see the app, visit http://apps.facebook.com/find-your-calling.)

In the 1.0 version of the app, we have been pulling data from the Drupal database via direct database queries, or else, for pages that require complex rendering, like the Training Tab, which uses AJAX Quicktabs + Views, we have been using an iframe, with Ben Alman's jQuery cross-domain communication plugin to handle the iframe resizing.

Neither of these solutions scale well, however, since if we want more data in the JSP-based app from Drupal via direct query, we need to write new Java/JSP code to get the node information. On the other hand, if we want to add new pages from www.urbanministry.org via iframe we have to use a combination of JavaScript techniques to get to work, and the potential for bugginess is high.

So I'm wondering what would be the best solution moving forward. I am considering the following, ranked in order of likelihood.

1) Use Drupal's multi-site feature to create a drupal.christianvolunteering.org, which would run off the same database as www.urbanministry.org, but would be excluded from search engines by robots.txt, and which would have the same theme as the application (set via ThemeKey + ThemeKey Properties).

That way, we would have one parent domain across which sessions could be managed more easily than with the hack (called Cookie Login) which we are currently using.

We might still need to use iframe's if we didn't want to add all the app-related Facebook JS code onto the UM.org Facebook theme. However, we wouldn't have to worry about the same-origin policy.

2) Use JSON (actually, JSON-P, unless we do #1 also) to insert content from the Drupal site into the JSP site's DOM tree. This would potentially appear slower though, since the content would appear "late", and it would have other potential issues. (For one, I'd have to use hook_url_outbound_alter, probably, on the Drupal side to rewrite all the relative links as absolute. Also, Javascript, especially that involving AJAX (such as Quicktabs and Views) would potentially be seriously broken.)

3) Use XML-RPC (i.e., Services) to insert content from the Drupal site server-side. This would be safer than JSON, but wouldn't solve the problem of having to do code releases, since we'd have to define in our JSP pages where the content would get inserted.

4) Keep on doing more things with iframe's - for one, we could have a footer in the application with links to a specific page on the JSP domain that contained an iframe of a page on the Drupal site, but each link would have a hash or query string parameter that was the encoded URL of a page on the Drupal site. Then, that hash or query string would be used to set the src of the inner iframe - that is, the iframe on the JSP site (FB app) which displayed the Drupal content.

5) Using a cron script to wget content from the Drupal site, save it as a static file, and include in .jsp.

For completeness, I suppose I should include:

6) Rewrite the whole app to run in Drupal, on one domain. However, I can't imagine my boss agreeing to this, since we spent quite some time on the initial development of the app, and the primary feature - the personality quiz - would need to be rewritten as a Drupal module. (Still, I think it would probably be easier to write as a Drupal module than it was in Java/JSP.) Also, the main reason we use JSP at all is because it is dramatically faster than our Drupal site, even though it queries from the same database.

Anyway, those are the options. I would appreciate any suggestions people have.

Facebook API

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: