Facebook uygulaması geliştirmek veya varolan uygulamanıza facebook güzelliklerini entegre etmek bir çok dilde (javascript, php vs) sdk'lar yardımı ile çok kolaylaştı. Fakat standart dışı işler yapmaya başladığınızda veya uygulama zekanızda birden fazla facebook methodunu zincirleme kullandığınızda, standart methodların yapamayacağı şeylere ihtiyaç duyabilir veya uygulamanız ile facebook API arasındaki iletişimini optimize etme ihtiyacı duyabilirsiniz.

Örnegin facebook'u üye kayıdı için kullandınız ve üye kaydında üye bilgilerini, üyenin fotografının orijinal versiyonunu (yüksek çözünürlüklü versiyonunu) ve arkadaş listesini uygulamanızda kullanacaksınız. Bunlardan ikisini (kullanıcı bilgilerini isteme ve arkadaş listesini istemeyi) neredeyse tüm facebook sdk'lerindeki standart methodlarla yapabilirsiniz. Ancak profil fotografının orijinal boyutunu almak için birden fazla şey yapmanız gerekebilir, ayrıca ortada düzgün bir method yok bunun için. Biraz hack gibi de olsa bilinen bir yöntemle bunu elde etmeye çalışacağızö dökümanın iletleyen kısımlarında buna değineceğim.

Biliyorsunuz facebook FQL (Facebook Query Language) denilen bir çeşit SQL dili kullanıyor. Geliştirici dökümantasyonunda tablo listesini ve her tabloya ait veri yapısını bulabilirsiniz. Ayrıca hangi veri türüne erişebilmek için hangi izinlere sahip olmanız gerektiği de dökümantasyonda veriliyor:http://developers.facebook.com/docs/reference/fql/

FQL'in güzel kısmı, birkaç basit SQL yapısını destekliyor olması. Çok gelişmiş şeyler yapılamasa da basit sub querying ile birçok işi kolayca halletmeniz mümkün.

En basit iki örnek olan kullanıcı bilgisi ve arkadaş listesi elde etmek için şu iki FQL'i kullanabilirsiniz.
SELECT uid, username, email, name, sex, birthday_date, verified FROM user WHERE uid = me()
FQL'de * şeklinde tüm kolonları seçme veya herhangi bir alanı seçici olarak kullanama seçeneğiniz yok. İstediğiniz tüm alanları belirlemeniz gerek. Ayrıca "WHERE birthday_date < '1980'" gibi bir seçici yazamazsınız. Dökümantasyonda da belirtilen ve sadece taranabilir (indexable) olarak tanımlanmış alanları kullabilirsiniz. Bunlar id, username gibi genel seçiciler.

Bu FQL size tek satırlık bir sonuç dizisinde, kullanıcı bilgisini istenen alanları verecektir. Gördüğünüz gibi secicide me() fonksiyonunu kullanarak giriş yapmış olan kullanıcıyı id'sini elde etmeye çalışmadan FQL'de kulanabiliyoruz. Ya da idsini bildiğiniz bir kullanıcı için bir veri isteginde bulunabilirsiniz. Ancak eğer istek yaptığınız kullanıcı, istenen tüm alanlara erişim için uygulamanıza izin vermediyse hata alacaksınız. Yani istek yaptığınız kullanıcının özel bilgilerini sorguluyorsanız, o facebook kullanıcısının, uygulamanızı kurarak gerekli izinleri vermiş olması şart.

Arkadaş listesini almak için kullanacağımız FQL:
SELECT uid, name, pic_square FROM user WHERE uid IN (SELECT uid2 FROM friend WHERE uid1 = me())
Bu FQL aynı zamanda nasıl sub query kullanabileceğinizi gösteren bir örnek. İç sorguda giriş yapmış kullanıcının arkadaşlarının id listesini alıyoruz, sonra genel kullanıcı bilgisi sorgulayabildiğimiz tabloda (users) bu listeyi sorguluyoruz. Arkadaş listesinden alabileceğiniz veriler de sınırlı. Yani her bilgiyi sorgulayamıyoruz.

Az önce bahsettiğim profil fotografının orijinal yanı büyük versiyonunu elde etme işi bir parça hack sayılabilir. Yani kabul edilen bir method değil, fakat işe yarayan ve kullanılan bir method. Kullanıcınızdan user_photos iznini aldığınızda kullanıcınızın tüm albümlerini ve fotograflarını okuma hakkina sahip oluyorsunuz. Aşağıdaki FQL'i kullanarak profil fotografının orijinal boyutuna ulaşabilirsiniz:
SELECT src_big FROM photo WHERE pid IN (SELECT cover_pid FROM albüm WHERE owner = me() AND type = 'profile')
İç sorguda albüm tablosundan "profile" türündeki tekil ve özel olan albümün (bu albüm, profil fotografları albümü) cover_pid yani cover fotografının id'sini sorguluyoruz. Bu bize son yüklenen profil fotografının idsini veriyor. Sonra da fotograflar tablosundan src_big yani büyük boyut (genelde orijinal boyutu saklıyor facebook bu alanda) adresini istiyoruz.

Optimizasyon demiştik

Kodunuzu FQL ile çalışır hale getirmek, 3 farklı isteği ayrı ayrı çağırmanızı değiştirmeyecektir. Yani işimiz burada bitmiyor eğer optimizasyon yapmaya çalışıyorsak.

Eski API'de tek istekte birden fazla FQL sorgusu yapmanızı sağlayan bir method vardı, başka şekillerde aynı method halen facebook tarafından sağlanıyor. Bu method ile dizi şeklinde tüm sorgularınızı isteyebilir ve büyük bir nense şeklinde tüm sonuçları tek seferde alabilmenizi sağlıyor. Böylece, zincir istekleri tek isteğe indirip aynı zinciri facebook sunucularına delege etmiş olursunuz. Facebook genelde sizin 3 ayrı istek yapmanızdan çok daha hızlı şekilde istekleri sorgulayıp dönecektir.

Facebook aynı methodu farklı şekillerde sunmaya devam ediyor. Fakat ben size en genel olan methodu önerecegim. İstekleriniz FQL olsun olmasın, birden fazla opengraph isteğini tek seferde isteyip cevap alabildiğiniz method batch requests olarak adlandırılıyor. Bu yazı daha çok FQL'ler üstüne olduğu için batch requests üstüne başka bir yazıda değineceğim. Batch Requests hakkında detaylı bilgiyi facebook dökümantasyonundaki ilgili sayfadan edinebilirsiniz:https://developers.facebook.com/docs/reference/api/batch/
Eger php tabanlı bir facebook uygulamanız varsa facebook'u sadece kimlik doğrulama dışında kullanıyor olabilirsiniz. Çok basit bir uygulamada bile en azından düzenli yaptığınız facebook api çağrıları vardır. Basit bir örnek ile, kimlik doğrulama sonrası arkadaş listesini ekrana basan ve seçtiğiniz arkadaşınızın doğum tarihini kullanarak bir hesaplama yapan bir uygulamanız var diyelim (mesela: doğum günü takvimi uygulaması). Biliyorsunuz ki arkadaşlarınızın doğum tarihi bilgisini ancak ek bir izin ile sorgulayabilirsiniz. Dolayısıyla kullanıcınız, bir arkadaşını seçtiğinde, seçilen facebook kullanıcısı detaylarını sorgulamadan önce, uygulamanızı kullanan kullanıcıdan o izni alıp almadığınızı kontrol etmeniz gerekir.

Uygulamanızı gerekli kontrolleri yaparak hata vermeyecek şekilde hazırladınız diyelim. Performans problemleri yaşıyorsanız, önce performans probleminizin nereden kaynaklandığını tespit etmeniz gerekir. Gerekli veritabanı ve php kod optimizasyonu yapmanıza rağmen hala performans problemleri yaşıyorsanız problem yüksek ihtimalle sunucunuz ile facebook sunucuları arasındaki iletişimin uzun sürmesidir. Bunun da en büyük kaynağı facebook sdk'sının kaç çağrı yaptığı, bunların toplamda ne kadar zaman aldığı olacaktır ve bu konuda bir fikriniz yok diyelim.

Bu noktada ufak bir değişiklikle sunucunuz ile facebook sunucuları arasındaki trafiği monitöre edebilirsiniz. Bu gözlem, aslında her cağrıda yapmak zorunda olmadığınız ama bilmeden yapıyor olduğunuz veya geçici şekillerde ön bellekte saklayabileceğiniz bilgileri, kontrolleri gösterecektir size.

Şimdi ufak bir değişiklikle trafiği yakalayalım. Bunun için base_facebook.php dosyasında olan api methodunu:
public function api(/* polymorphic */) {
	$args = func_get_args();
	if (is_array($args[0])) {
		return $this->_restserver($args[0]);
	} else {
		return call_user_func_array(array($this, '_graph'), $args);
	}
}
aşağıdaki şekilde güncelliyoruz:
$facebookApiCalls = array();
public function api( /* polymorphic */)
{
	$args = func_get_args();

	$time_start = microtime(true);

	if (is_array($args[0])) {
		$result = $this->_restserver($args[0]);
	} else {
		$result = call_user_func_array(array($this, '_graph'), $args);
	}

	$time_end = microtime(true);
	$time_elapsed = $time_end - $time_start;
	$time_elapsed *= 1000; //convert to millisecs

	if (isset($GLOBALS['facebookApiCalls'])) $GLOBALS['facebookApiCalls'][] = array(
		'duration' => $time_elapsed,
		'args'     => $args,
	);
	return $result;
}
Yukarıdaki kodda yaptığımız değişiklik basitçe api methodu her cağrılışında, facebook sunucularına yapılan http isteğinin ne kadar sürdüğünü ölçüp global bir dizide toplamak. Bu şekilde sayfanızın sonunda ekrana $facebookApiCalls dizisini bir tablo şeklinde veya basitçe var_dump alarak kaç çağrı yapıldığını, yapılan cağrıların her sayfada tekrar edip etmediğini gözlemleyip eğer yapılabiliyorsa ön bellekte veya oturum değişkenlerinde tutularak sorgu tasarrufu yapılıp yapılamayacağına karar verebilirsiniz. Eğer sorgularınız çok zaman alıyorsa sunucu trafiğinizde optimizasyonlara gidebilirsiniz.

Bir çok amatör programcı, sdk methodlarını veya bilindik open graph methodlarını kullanarak sorgu yapıyor ve çoklu işlem yaparken ayrı ayrı sorgu yapıyorlar. Aslında facebook veri yapısını biraz anladıktan sonra FQL yazarak birden fazla sorguyu tek sorguda toplayıp önbellekleyebilir ve bu sayede çok büyük bir optimizasyon sağlayabilirsiniz.

Yukarıdaki doğum günü takvimi örneği için yapılabilecek optimizasyon senaryosu şöyle olabilir: uygulama, "arkadaşların doğum tarihi" iznini her halukarda gerektiriyorsa ilk sayfa açılışında kontrol edilerek kullanıcının bu izni vermesine zorlanabilir, bu sayede her arkadaş seçiminde ayrı ayrı kontrol yapılmak zorunda kalınmaz. İkinci bir optimizasyon, arkadaş listesinin önbelleklenmesi olabilir. Hatta doğum günleri de arkadaş listesiyle sorgulanarak tek oturumda sadece tek istek ile uygulamanızı çalıştırmış olursunuz.

Bu optimizasyonlar sadece uygulama hızı için değil, sunucu trafiğinizi azaltmak için de düşünmeniz gereken optimizasyonlardır.

Popüler Etiketler

html object less css compile compiler macosx windows linux app on-the-fly mootools facebook api opengraph fql optimization wanda digital pharma hack php wordpress blog rss ios apple itunes mobile banner meta doritos kampanya tytz network social twitter jquery javascript widget internet css3 ubuntu ntfs fstab html5 form input media sosyal integration service internet explorer while bootstrap örnek kod htaccess mod_rewrite url cookie assets cache firefox logo imza signature mail subdomain mysql optimizasyon startups music js zaman wireless share proje cms textarea kurulum nasıl medya parse xml apache applications free svn subversion export auth http download mfyz kontrol yapıları if switch db code pear mdb2 prepare execute mssql pgsql iphone ipad app store store in-app purchase purchase subscription verification storekit itunes connect kitap ui design development gimp icon ikon grafik calendar newsletter google chart osx portfolio license istatistik statistics graph server table ipucu session developer ux icons login sql tool insanlar link howto sitemap seo iOS coding www redirect crossdomain notebook laptop lisans support plugin regex ruffles generator language style lifestream workspace radio button open source xhtml box database analyse procedure search route router spam screen konsol terminal xmlhttprequest ajax oyun ie connect browser dokuman date diff player tebrik tarih nedir browsers injection query select job git version control deployment framework ide editor phpstorm jetbrains webkit web app