Facebook hepimize web sitesi geliştirmeyi öğretti
Bazen yazılım geliştirmede, dev sıçramalar gerçekleştiriyoruz.
2003 yılında, Brad Fitzpatrick Memcached’ i (açık kaynak kodlu, yüksek performanslı, dağıtık mimaride çalışabilen bir önbellekleme sunucu sistemi) yayınlandı ve LiveJournal mimarisinden (buradan bir kaç yıl sonraki bir sunuma göz atabilirsiniz) bahsetmeye başladı. Bu bir sonraki neslin siteleri ve uygulamaları için bir prototip haline geldi, günümüzde de web uygulamalarını büyük oranda aynı şekilde geliştirmeye devam ediyoruz.
2004 yılında, Google MapReduce’ u anlatan bir makale yayınladı. Google'ın bu programlama modelini yayılmasıyla bu makaleden esinlenen Hadoop doğdu. Hadoop büyük ölçüde gelişmesi, onu büyük sitelerin ve uygulamaların veri işlemelerinde vazgeçilmez bir parça haline getirdi.
2007 yılında, Amazon, veritabanlarının ve uygulamaların birlikte çalışması ve ölçeklendirilebilmesi için nasıl geliştirilebileceklerini, anlaşılır bir şekilde anlatan Dynamo makalesini yayınladı. Bu kavramla birlikte, Cassandra ve RIAK gibi bir sürü veritabanı ortaya çıktı ve tüm dünyadaki uygulamaların çoğunda kullanıldılar.
2010 yılında, Twitter açıkça sunucuları basit bir API haline getiren istemci tabanlı şablonlamaya (client-side templating) geçti. Aynı zamanda, DocumentCloud bu kavramı düzgün bir API, yeni bir implemantasyon ve net dokümantasyon ile paketleyerek Backbone.js’i yayınlandı. Twitter beş yıl önce bir kaç duraksama yaşasa da, pratikte bu, bugün çoğu uygulamanın istemci üzerinde render edildiği ve her gün bu tarza çevrildiği büyük geçişi başlattı.
2012 yılında, Google Angular.js ‘in 1.0 sürümünü yayınladı. Angular.js Backbone.js’den daha fazla yapı sağladı, ve veri bağlama ve içeriği render etmenin sıkıcı taraflarının üstesinden gelerek, test sürecini ve en iyi geliştirme pratiklerini ön plana çıkardı. Bugün, herhangi bir web geliştirme için aranan pozisyonlara baktığınızda göreceksiniz ki hepsinin bilinmesi gereken kütüphaneler listesinde Angular.js var, popülaritesindeki yükseliş ışık hızında ilerliyor.
Bütün bunların ortak noktası ne? Şirketler veya girişimler, üretimde zor dersleri öğrenerek, ileri bir yol buldular ve bu çığır açan buluşlarını tüm dünyayla paylaştılar.
2015'te de bu sefer bunun Facebook’un React.js, Relay ve GraphQL üçlemesiyle tekrar gerçekleştiğini düşünüyorum.
Bu hafta Facebook tarafından sunulanı, uygulama ve site geliştirme açısından, dışarıdan biri olarak şu şekilde yorumluyorum:
1-Uygulama fikrinizi bileşenlerine ayırın. Bazı bileşenler uygulamanın birçok parçasında tekrar kullanılırken, bazıları ise sadece bir kez kullanılacak ama tüm bu bileşenler iç içe geçerek sizin uygulamanızı oluşturucaklar.
2-Her bileşen kendisini render etmek için gereken herşeyi içeren veriyi (state) tutmalıdır. Uygun olduğu sürece, durum değişkenleri için sabit(immutable) veri yapıları kullanın.
3-Bileşenlerin, kullanıcı davranışıyla veya başka bir bileşenin neden olduğu durum değişikliklerine nasıl tepki vereceğini tanımlayın ve açıkça adresleyin.
4-Bütün bileşenlerin kendilerini render etmeleri için gereken veriyi tam olarak ve açıkça tanımlayın.
5-Her bileşenin yanına tasarımını, biçimini, doğrulamasını ve veri gereksinimlerini yerleştirin.
6-Eğer farklı markupları yazmayı öğrenirseniz, aynı teknikleri, dili, framework’ü ve kütüphaneleri native uygulamalar geliştirmek için kullanabilirsiniz. Eğer şanslıysanız, bazı ortak kodları bunların hepsinde aynı şekilde kullanabilirsiniz.
Diğer herşey framework, derleyici ve araçlar tarafından halledilmelidir. Örneğin:
- Bileşen durumu değiştiğinde, framework DOM’u (veya iOS/Android ekran hiyerarşisini) bileşenin kendisinin nasıl görünmesi gerektiğini belirttiyse o şekilde değiştirmesi gerektiğini bilmelidir.
- Üç bileşenin hepsi birden veri isteğinde bulunduğunda, framework veri almak için sunucuya gönderilmesi gerken en verimli sorguyu veya sorgu serisini, nasıl derlemesi gerektiğini bilmelidir.
- Durumdaki değişiklikler uygulamanın kullanıcı arayüzü katmanına, sunucu ile onaylanarak en iyi şekilde yansıtılmalıdır.
- Sayfa yüklendiğinde, HTML’i render etmelidir, ama tarayıcıya yüklendiğinde yeniden başlamalı ve tekrar interaktif hale gelmelidir.
Bu yol neden uygulama geliştirme için böylesine iyi bir düşünme yoludur? İster sunucu tarafında olsun ister tarayıcı, biz her zaman ölçeklenebilirlik hakkında konuşuruz. Geliştirici takımlarını ölçeklendirmek hakkında ise çok az konuşuruz. Bu muhtemelen problemin zorluğundan kaynaklanıyor. İşte burası Facebook’un devreye girdiği yer.
Bu tekniklerle yazılan bileşenler kendi mekanizmalarını içerebiliyorlar, bu şekilde uygulamanın diğer parçalarını bilmek veya bozmak gibi endişeleri olmuyor. Bu bileşenler standartlaştırılarak tekrar kullanılabiliyorlar, böylece ufak değişiklikler için aynı butonu on farklı şekilde tekrar implemente etmek zorunda kalmıyorsunuz. Bileşenleri geliştirmek için gereken temel küme küçük olduğundan ve altında büyük bir karmaşıklık olmadığından dolayı yeni geliştiricilerin işe alımı kolaylaşıyor. Bu şekilde bu mimari zarif bir mimari haline geliyor.
Bir yandan da bu teknik bizleri, arayüz değişimlerini yazmaktan daha planlı bir sunum yolu olan arayüz durumları ve durum geçişleri hakkında düşünmek için zorluyor. Bu şekilde bu sınıftaki tüm yazılım hatalarını önlüyor.
Facebook’un bu geliştirmelerinden (GraphQL, Relay, React Native) bazılarını yayınlamasını bekliyoruz ve görüyoruz ki yavaş yavaş kaynakları dışarıya açılıyor. O zamana kadar, henüz denemediyseniz, React.js’ e bir göz atın. Bir saat içinde anlar, ikinci saatte biraz eğlenirsiniz ve üçüncü saatte de bir görüş edinmiş olursunuz. İddia ediyorum görüşünüz bir daha hiç geriye dönmemek olacak.
