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.
21 Temmuz Cumartesi ´12   —   2 Yorum

OpenGraph nedir?

OpenGraph Facebook'un APIsi için oluşturduğu yeni bir API (Application Programming Interface: Uygulama geliştirme arayüzü) yapısıdır. Proje, genel bir yapıda hazırlandığı için belki standartlaşma ihtimali de var fakat şu an için sadece Facebook kullanıyor.

Neden OpenGraph?

Şu an için zaten sadece Facebook ile kullanabileceğiniz opengraph yapısı, aslında bir uygulama ortamı için özelleştirilebilir esnek bir api yapısı. Yani Facebook'un klasik RESTful API'sinde Facebook'daki bilgiye ulaşabiliyor ve yönetbiliyordunuz. Bunlar hala mevcut ama Facebook'un veri yapısı için tasarlanmış methodlar olduğu için facebook ortamındaki bir facebook uygulaması bu api kanalını kullanamıyordu. Yani Facebook veri yapısına bağımlıydı.

OpenGraph'ın çıkış noktası, internetteki herşeyi içerik olarak özetlemek. Yani adresi belli olan herşey bir içerik olarak kabul ediliyor. Bunu ise linkler ile adresliyor Facebook; mantıklı bir yaklaşım aynı zamanda. Yani her url'in bir içeriği sunduğu düşünülüyor, daha spesifik olarak bu içerikleri istediğiniz kadar parametre ile detaylandırabiliyorsunuz. Bu tanımlamaları yapaken html/xhtml içeriğinizde opengraph ön ekli parametreler kullanarak yapabiliyorsunuz. Facebook'un genel opengraph parametreleri sayfa yani içerik hakkında genel bir bilgi içeriyor.

Bunlardan birkaçı;
og:title         sayfa başlığı
og:description   sayfa tanımı
og:image         sayfayı temsil eden görsel
og:media         sayfa, bir medya sunuyorsa onun doğrudan adresi (video, ses vb)
Bu etiketleri sayfanıza eklediğinizde, biri sayfanızın adresini facebook'da paylaştığı zaman o sayfaya ait içeriği temsil edecek görsel, medya içeriği, içerik tanımı gibi detayları facebook yakalayabiliyor.



Opengraph'ın asıl esnekliğini görebileceğiniz şey, içeriğinizi gerçekten tanımlayacak özel değerleri kendi oluşturacağınız etiketlerle belirleyebilmeniz. Bu yapı aslında sadece facebook için değil genel bir web yaklaşımı için tasarlanmış bir şey. Yani google da opengraph etiketlerini tarayarak sayfanız hakkında özel bir indeks oluşturabilir.

Örnegin bir araba modelinin detay sayfasını tanımlarken, sadece sayfa başlığı, açıklaması veya arabanın görseli o sayfadaki içerik hakkında yeterli bilgi vermeyebilir. Özel olarak arabanın üretim yılı, markası, yolcu kapasitesi, rengi gibi değerleri de belirleyebilirsiniz.

OpenGraph'ın çıkış amacı, Facebook kullanıcılarının aktivitelerini daha detaylı ve özel bir şekilde göstermek istemesi. Facebook ilk "like" butonunu genelleştirdi ve şu anda web'de bir çok sayfada like butonunu kullanıyor herkes. Eğer bir sayfayı beğenirseniz kullanıcı profilinizde "Mehmet, XYZ sayfasını beğendi" şeklinde görünüyor. Ama OpenGraph ile hedeflenen şey, bu kullanıcı aktivitelerini uygulama geliştiricilerine iyi bir yapı ile sunmak. Şu an bir uygulamayı kullandığınızda o uygulama, uygulama içinde yaptığınız aktiviteyi daha detaylı şekilde "Mehmet Ortakoy'de fotoğraf çekti" veya "Mehmet BMW M3 ve 4 diğer araba modeliyle test sürüşü yaptı" gibi çok daha detaylı bir kullanıcı aktivitesi yayınlayabiliyorsunuz.



Bunun için Facebook geliştirici arayüzlerinde önce OpenGraph nesnenizi tanımlamanız gerekiyor. OpenGraph'da her nesne bir web adresi demek ve bu web adreslerini o içeriği sağlayan sayfalar olarak düşünün. Bir diğer parça da "aktivite" tanımı. Yukarıdaki araba örneğinde, "araba" bir nesne, ve sayfamız bir araba detay sayfası, kullanıcı aktivitesi de "test sürüşü yapmak". OpenGraph ile aktivite, nesne tanımı yapıp kullanıcı aktivitesi yayınlamakla ilgili başka bir yazı hazırlayacağım fakat burada açıklayabilmek için daha detaylı bir örnek vermem gerekiyordu.

Neden Facebook uygulamanızı OpenGraph'a geçirmelisiniz?

Şu an halihazırda bir Facebook uygulamanız var olabilir. Uygulamada yapılan aktiviteye ilgili bir içeriği veya aktiviteyi kullanıcının profilinde paylaşıyor olabilirsiniz. Muhtemelen paylaşımda bulunduğunuz içerik genel bir durum güncellemesi gibi görünüyor, genel bir link ile başlık, açıklama ve görsel içeriyor.

Facebook kullanıcı adına paylaştığınız bu içerikleri kısa, uzun, gruplanmış veya topluluğu özetleyecek şekilde şekillendiremez çünkü her girdiyi gruplayacak veya birbiriyle ilişkisini ortaya koyacak bir bağ yok. OpenGraph burada devreye giriyor ve Facebook, nesneler, aktiviteler veya aynı aktiviteyi yapan birden fazla arkadaşınızı tek haber olarak gösterebiliyor.

Yukarıdaki örneği devam ettirsem, benim dışımda 2 arkadaşınız daha "test sürüsü" yapmışsa facebook benim aktivitemi ve değer 2 arkadaşınızın aktivitesini size "Mehmet ve 2 arkadaşınız daha test sürüsü yaptı" olarak gösterebiliyor. Hatta eğer aktiviteniz anlık değil zaman alan bir aktivite ise bunu daha önceden tanımlanmış olan bir OpenGraph özelliği olan eylem uzunluğu ile belirtebiliyorsunuz. Örnegin Facebook, şu an halen devam eden ve aynı nesneyi (yani içeriği) kullanarak aynı eylemde buluan arkadaşlarınızı tek hikayede gösterebiliyor "Mehmet ve Betül şu an Indiana Jones izliyor" (eylem: izlemek, icerik/nesne: Indiana Jones). Gurplama, sadece birden fazla arkadaşınızın aynı eylemı yapması şeklinde olmak zorunda değil. Bir arkadaşınızın aynı türde eylemi farklı nesneler (içerikler) ile yapması da düşünülebilir. Bir önceki ekran görüntüsündeki gruplanmış hikaye, benim Songza uygulamasını kullanarak Johannes Brahms playlistini dinlememi gösteriyor. Fakat songza bu haberi bu şekilde kendisi gruplamıyor. Songza'da her dinlediğim şarkı için Songza OpenGraph ile hangi şarkıyı dinlediğimi facebook'a gönderiyor. Bu içerikler aynı türde içerikler olduğu için bu şekilde tek hikaye olarak görünmeye başlıyor. Bu içerikleri tek seferde dinlemiş olmak zorunda da değilim. Gerekli gruplamayı facebook yapıyor. Biz sadece içeriklerin türleri, birbirleri ile ilişkilerini bildiriyoruz facebook'a. Ekran görüntüsünde görebileceğiniz gibi bu playlist'i tek seferde dinlememe göre değil aynı zamanda bir tarih aralığındaki (ekran görüntüsündeki hikayenin alt kısmında Jul 10 - July 16 şeklinde 6 günlük bir zaman dilimi için) benzer aktivitemi gruplayarak göstreiyor Facebook.

Yukarıdaki faydalar Facebook ortamı için olan faydalar olarak görünebilir fakat, bu hikayelerin göründükleri yerler farkettiğinizden çok daha fazla. Normalde klasik paylaşımda bulunan uygulamanız, kullanıcının profilinde bir içerik paylaştığında o hikaye sadece o kullanıcının profilinde ve o kullanıcının arkadaşlarının ana haber akışında görünüyor. Çoğu zaman ana haber akışı sayfasında (news feed) görünemiyor çünkü yorum yapılan, otomatik olmayan gönderilmiş güncellemeler sizin hikayenizi önem sırasında gerilere itiyor ve çoğu zaman görünmez hale getiriyor.

Eğer OpenGraph'de bir hikaye yayınlarsanız hikayeniz, kullanıcı profilinde gruplanıyor, eğer 5 hikayeden fazla gönderim yapmışsanız bir kutu ile uygulama adınız ve kullanıcı aktivitesi görünümü değiştirilebilir bir şekilde kullanıcı profilinde görüntüleniyor.



Yukarıda, foursquare'de son 1 ayda kazandığım rozetleri gruplanmış bir şekilde görebiliyoruz. Bu gruplamayı yine facebook yapıyor. Facebook'un geliştirici panelinde, uygulama ayarlarında OpenGraph sekmesinde bu kutuları yani gruplanacak içerik/hikaye türlerini, gruplandıkları zaman ne şekilde gösterileceğini detaylı bir şekilde ayarlayabiliyorsunuz.

Bunun dışında facebook'a bildirilen her hikaye ayrı bir şekilde anlık olarak facebook anasayfasında (news feed) sağ tarafta olan "Ticker" alanında anlık olarak görünüyor ve arkadaşınız haber akışını okuyor olmak durumunda da değil. Bunun dışında eğer birden fazla arkadaşınız aynı aktiviteyi yapıyorsa o hikaye daha üst önem sıralarına çıkıyor. Yani içeriğiniz veya aksiyonunuz birden fazla kişinin yapmasıyla daha önemli hale geliyor.


OpenGraph'ın hikayelere tıklanarak içeriklere (yani sayfanıza) ziyareti arttırdığı bir gerçek. Bu konuda TechCrunch'da veya diğer teknoloji bloglarında spotify'ın ve pinterest'in OpenGraph ile ziyaret ve etkileşim oranlarını katladığını okuyabilirsiniz. Bu iki örnek şu an iki OpenGraph başarı hikayesi olarak verilebilir.


Hazırlayan: Mehmet Fatih YILDIZ

Popüler Etiketler

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