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.
Uzun bir dönem flash'ın webdeki baskınlığının sonucu olarak ekrana sığan sayfalar tercih edilmeye başlanmıştı ama hem mobil cihazların popülerleşmesi, hem blogların şu an internette çoğunluk içeriği sağlıyor olması hem de flash'ın hayatımızdan biraz daha çıkmasıyla, uzun sayfalar tekrar günlük web gezintimizde en sık karşılaştığımız sayfalar oldu. Uzun bir sayfanız var ise ve eğer metin ağırlıklı bir içeriğe sahip değilseniz muhtemelen içeriğiniz, resimler/fotograflar barındırıyor olacaktır. Bunun yanı sıra sayfanızda üst, alt veya yan alanlarda da görüntülediğiniz yardımcı içerikler olabilir.

Örnek ile basit bir wordpress blogunu gözünüzde canlandırırsanız sayfa başlığı, alt metni ve yan navigasyonda ilgili yazılar (ve bunlara ait küçük görseller) sayfanızın altında bulunan görseller, mesela sponsor logoları, statik reklamlar, birkaç ufak ikon (sosyal medya ikonlari) vs küçük büyük bir çok görseliniz olacaktır (footer, header, sidebar).

Uzun bir sayfanın en büyük tehlikesi içinde barındırdığı medya içeriği sayısı olacaktır. Eğer medya içeriği sayınız, dosya boyutları ufak medya içerikleri dahi olsa yüklenmesi uzun zaman alacaktır. Bu konuya birçok web opimizasyonu yazısında karşılaşabilirsiniz.

Şimdi çok daha anlaşılır bir örnekle bu konuyu hızlıca kod üstünde anlatacağım.

Kısa süre önce bir facebook uygulaması hazırlarken, hazırladığım bir sayfada o kullanıcının arkadaş listesini her satırda 4 avatar görünecek şekilde bir tablo şeklinde gösteren bir sayfa hazırladım. Kendi hesabımla sayfayı açtığımda 500+ arkadaş listeleniyordu ve bu da 500 avatar'ın bir sayfada olması anlamına geliyor. Sorun tabi ki internet hızı değil. Asıl problem tarayıcılar. Tarayıcılar, Her domain için, paralel iki yüklemeye izin verir ve her imajın 100 milisaniyede yükleniyor olduğunu varsayarsak, saniyede 20 fotoğraf yükleniyor diyebiliriz. 500 fotografın yüklenmesi de 25 saniye sürecektir.

Sayfa ilk açıldığında çok garip görünmüyor ama daha sayfa yüklenmeden sayfayı aşağı kaydırdığımda ekranda daha yüklenmemiş görseller görüyor oluyorum.

Bundan daha tehlikelisi bu görseller sayfanızdaki diğer kaynakların yüklenmesini geciktiriyor ve javascript akışınızı etkiliyor. Dolayısıyla iyi bir kullanıcı deneyimi değil. Zaten teorik olarak düşündüğünüzde de ekranda görüntülenmemiş belki de hiç aşşağı kaydırılarak görüntülenmeyecek medya içeriği yüklenmeye çalışıyor ve ideal olarak bunların ekranda görüntülenmeden yüklenmemesi gerekir.

Wordpress blogu örneğindeki problem şöyle olabilir. Her girdinizin bir görseli olduğunu düşünürsek ve arşiv sayfanızda her sayfada 10 girdi gösterdiğinizi düşünürsek sayfanızdaki diğer medyaların dışında uzun bir sayfada 10 görsel (yüksek çözünürlükte olabilir) görüntülenmeye çalışması performans kaybına neden olabilir.

Bu problemi bir javascript çözümü olan lazyload ile çözebilirsiniz. jQuery eklentisi olarak bulabileceğiniz eklentinin yaptığı şey her görseli jenerik bir yer tutucusu olarak yükledikten sonra o görselin ekranda görünür alanda olup olmadığını tespit ederek gerçek kaynaktan yüklemek.

Yani sayfanız yüklendiğinde bütün görseller aynı imajı yüklüyor. Genelde bu imaj 1 piksellik tek renk (gri örneğin) ufak bir görsel oluyor. Anında yüklenip tüm imajlarda yer tutucu olarak yerleşiyor. Sayfanız yüklendikten sonra lazyload, o sayfanın pozisyonunu ve görüntülenebilir alanını hesaplıyor ve görselin o alanın içinde veya yakınında olup olmadığını hesapladıktan sonra görünen imajlari yükleyip daha kaydırma pozisyonuna göre ekranda omayan veya uzak olan imajlari yüklemiyor.

Bir javascript eventi ile sayfa kaydırma hareketinizi izleyerek imajlari gösterdiğiniz anda yüklüyor.

Lazyload'i sayfanıza nasıl entegre edersiniz?

Önce bir yer tutucu görseli hazırlamalısınız, bunun için transparan veya sabır bir renk 1x1 boyutunda bir gif imaj hazırlayın.

Sayfanızdaki tüm görsel adreslerini bu imajı yükleyecek şekilde ayarlayın. İmajlarin gerçek adreslerini de "data-original" özelliğine alıyorsunuz.
<img data-original=“img/example.jpg” src=“img/grey.gif”>

Sonra jquery ve lazyload'ı sayfanıza ekledikten sonra bu imajları bir seçiciyle seçip lazyload'ı çalıştırıyoruz.
<script src="jquery.js" type="text/javascript"></script>
<script src="jquery.lazyload.js" type="text/javascript"></script>

$("img.lazy").lazyload();
Yukarıdaki kod "lazy" sınıfındaki resimleri yükleyecektir. Daha genel bir kullanım istiyorsanız sadece img etiketlerini belirterek sayfanızdaki tüm görsellerin lazyload ile yüklenmesini sağlayabilirsiniz.

Bundan sonra sayfanızdaki görseller ekranda görüntülendikleri anda yüklenecekler. Lazyload dökümantasyonunu inceleyerek tolerans ataması yapmayı (yani görselin, sayfa kaydırılırken ekranda görüntülenmeden önce yüklenmesini saglayabilir) veya görüntülenirken bir geçiş animasyonu belirleyebilirsiniz.

Proje adresi:http://www.appelsiini.net/projects/lazyload
Website optimizasyonu konusu büyüyen startupların artık başta düşünmeye ve endişe duymaya başladığı bir konu. Bir web sayfasının optimizasyonu konusunda birçok detaycı yaklaşım var, bunlardan birisinden bahsedeceğim şimdi.

Web sayfanızda sayfa dışında yüklediğiniz bir çok dosya var. Bunlar genellikle imajlar, css ve javascript dosyaları. Tabi bunun dışında flash nesneleri, activex nesneleri, java nesneleri gibi başka dosyalar da olabilir. Bu dosyaları tarayıcı sunucudan isterken eğer domain cookie açık bir domain ise her istekte sunucunuza, istemcinizdeki cookie içerikleriniz gönderilir. Aynı şekilde sunucu da size gönderir.

Eğer o domainde çalıştırdığınız uygulamanız çok cookie set etmemişse bu konunun çok önemi olmaz ancak uygulama geliştiricinin ne yaptığını bilemezsiniz ve uygulama geliştirici de bu konuyu düşünerek "daha az cookie set etmeliyim" yaklaşımı ile uygulama geliştirmez. Yani eğer çok cookie barındırıyorsanız veya cookie içerikleriniz büyükse (mesela bir formun state'inin encode edip büyük bir text olarak saklıyor olabilirsiniz) bu imaj (js, css) transerlerinde bir de bu cookieler gönderilip alınacağından belli sayıda dosyadan kayda değer bir yavaşlama hissedilecektir.

Özellikle .NET'deki authentication cookie'leri gibi büyük boyutlu cookie saklayan uygulamalarda, eğer http request sayınız çok ise bu yavaşlama hissedilir derecede olabilir.

Bunu engellemek için uygulamanızı sunduğunuz domain ile bu statik dosyaları sunduğunuz sunucuyu ayırmalısınız. Sunucuyu ayırmaktan kastım fiziksel olarak ayırmak değil. Mesela mfyz.com domaini için konuşursam, uygulama mfyz.com üzerinde çalışıyor ve kullanıcı bu domainden girip burada kalıyor. Ama bununla beraber gelen birçok statik dosya cookie disabled bir subdomainden sunulabilir. Mesela statik.mfyz.com gibi bir subdomainden sunulurken, uygulamada header'da include ettiğim bir js dosyası için
<script type="text/javascript" src="http://mfyz.com/js/main.js"></script>
yerine
<script type="text/javascript" src="http://statik.mfyz.com/js/main.js"></script>
kullanmam yeterli olacaktır.

Gelen giden trafikte cookie'ler gönderilmeyeceğinden ve alınmayacağından transfer boyutları azalacaktır. Bu değişim birkaç dosyada bir anlam taşımayacaktır ama çok dosyada anlamlı olabilir.

Dediğim gibi çok detay bir konu ama yapmasanız da böyle bir faktör olduğunu bilmelisiniz.

Popüler Etiketler

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