Facebook API – IFRAME or FBML(二)

除了Facebook Chat某個程度上突顯出了IFRAME模式的優點, XFBML的引入更讓IFRAME的運作更有效率. 在XFBML之前, IFRAME模式下如果要取得Facebook上的Social Content, 必須在你的應用程式伺服器上與Facebook Server進行多次的API Call, 然後才能將整合了Social Content的頁面內容回傳到使用者的瀏覽器中. 但是在使用了XFBML之後, 身為開發者的你可以直接在IFRAME呼叫的程式裡勘入FBML的Tags, 然後透過引入Facebook所提供的Javascript去掃描整個頁面的DOM去取出所有位於fb命名空間下的Tag進行 一次批次性的API Call去取得social Content然後進行DOM的替換, 而其他不屬於fb Namespace下的DOM元素將會在API Call完成之前就顯示於頁面之上, 甚至開發者還能將一些資訊於應用程式伺服器上進行快取, 連API call的Round Trip都能省了下來, 這樣的做法大大的提升了IFRAME的效能.

以下我嘗試拆解整個流程

• IFRAME Canvas Page使用XFBML - 使用者第一次載入頁面的情境
  
  1. 使用者的瀏覽器發出連線到應用程式的Request到Facebook
     
  2. Facebook Server回傳fb Chrome給使用者的瀏覽器
     
  3. 瀏覽器根據fb Chrome內的IFRAME對你的應用程式伺服器發出Request
     
  4. 如果IFRAME的內容中有需要發出Facebook API Call的請求, 此時在Facebook Server與APP Server間會有一次或是多次的Round Trip
     
  5. App Server將IFRAME的內容回傳到User的Browser內
     
  6. User的Browser會利用引入的Facebook Javascript Library進行整個頁面DOM的掃描去取出所有fb Namespace的元素然後進行批次的API Call, 而其餘的不數於fb命名空間下DOM會在API Call的同時先顯示於瀏覽器之中.
     
     而API Call所回傳的Social Content可以快取在客戶端, 當User於下一次Reload Page之時, 就不會發生與Facebook Server之間的Round Trip 
     
  7. 待API Call完成之後, fb Namespace下的Tag將會替換成相對應的Social Content
     
• IFRAME Canvas Page使用XFBML - 使用者已載入頁面後的Page Reload情境
  
  步驟1~5一樣, 主要的差別在於如果有在第一次載入面頁的時候將Social Content快取在客戶端的話, 連第6步中與Facebook Server間的Round Trip都可以省下來了, 如此一來讓IFRAME運作起來就像一般的網頁一樣. 除了Social Content會在其他不屬於fb Namespace下的DOM先顯示完成後才會呈現.