Bir özelliği üç katmanda (API, web, mobil) birden teslim etmek
Tek bir özelliği API, web ve mobil katmanlarında birlikte teslim etmenin uçtan uca akışı; Looplio üzerinde edindiğim pratik.
Looplio’da bir özelliği “bitirdim” demek, eskiden tek bir kod tabanını bitirmek demekti. Artık öyle değil. Ürünün üç katmanı var: Laravel ile yazılmış bir API, aynı API’yi tüketen bir web uygulaması ve React Native ile yazılmış bir mobil uygulama. Bir özellik, üçünde de yaşamadan teslim edilmiş sayılmıyor.
Bu yazı, tek bir özelliği bu üç katmanda birden teslim ederken oturmuş düzenimi anlatıyor.
Sözleşmeden başlıyorum
Artık koda değil, sözleşmeye başlıyorum. Yeni özelliğin API’de hangi uçları, hangi alanları, hangi hata durumlarını üreteceğini önce yazıya döküyorum. Bu, on dakikalık bir iş ama sonraki günleri belirliyor: web ve mobil tarafı, sözleşme netleşmeden tek satır yazmıyorum.
Bu disiplini edinmeden önce sık yaşadığım şey şuydu: API bir alanı tarih diye döndürürken mobil tarafı tarihi bekliyordu ve bunu ancak entegrasyonda fark ediyordum. Sözleşmeyi önce yazmak bu sınıf hataların çoğunu baştan eliyor.
Sözleşmeyi yazmak başka bir yan etki daha sağlıyor: özelliğin gerçekten ne yapması gerektiğini düşünmeye zorluyor. Bazen bu on dakika, “aslında bu özelliği bu şekilde değil, şu şekilde yapmalıyım” kararıyla bitiyor. Kod yazmadan önce bu tür bir revizyon yapmak, kod yazıldıktan sonra yapmaktan çok daha ucuz.
API katmanı — tek doğruluk kaynağı
İş kuralı yalnızca API’de yaşıyor. Web ve mobil, kural taşımıyor; yalnızca gösteriyor ve istek atıyor. Bu sınırı katı tutmak önemli, çünkü kural iki yere kopyalanırsa er ya da geç birbirinden ayrışıyor.
API tarafında özelliği yazıp testlerini geçtikten sonra, yanıtların sözleşmeye birebir uyduğunu doğruluyorum:
return UserPlanResource::collection($planlar);Resource sınıfı, veritabanı modelini istemciye doğrudan sızdırmadan, sözleşmede söz verdiğim şekli üretiyor.
Testler burada iki rol üstleniyor: özelliğin doğru çalıştığını kanıtlamak ve sözleşmeyi belgelemek. Yanıt yapısını test eden bir satır, “bu API şu alanları döndürür” diyen bir dokümandan daha güvenilir; çünkü test çalışıyor, belge eskiyebiliyor.
Web ve mobil — aynı veriyi iki dilde göstermek
API hazır olunca web ve mobil paralel ilerliyor. İkisi de aynı JSON’u alıyor ama farklı dünyalarda yaşıyor: web tarafında bileşenler, mobil tarafta React Native ekranları. Ortak noktaları, API yanıtının tipini ikisinde de aynı biçimde tanımlamam. Aynı alan adları, aynı beklentiler.
Burada öğrendiğim şey, iki istemciyi aynı anda yazmaya çalışmamak. Önce birini — genelde web’i — tam bitiriyorum; sözleşmenin gerçekten çalıştığını orada görüyorum. Sonra mobil tarafı, artık denenmiş bir sözleşmenin üzerine kuruyorum.
İki istemciyi paralel yazmak mantıklı gibi görünse de pratikte ikisinde de yarım kalmış, birbirinin sorununu çözerken karışan bir çalışma ortamı oluşturuyor. Sıralı teslim, her katmanda temiz bir odaklanma sağlıyor.
”Bitti” tanımım
Bir özellik bende şu üç koşul sağlanınca bitmiş sayılıyor: API testleri geçiyor, web’de gerçek bir kullanıcı akışıyla deneniyor, mobilde gerçek bir cihazda deneniyor. Üçü de yeşil değilse özellik yarım demektir.
“Gerçek bir cihazda” kısmı önemli. Simülatör ya da emülatörde çalışan bir şey gerçek cihazda farklı davranabiliyor; özellikle dokunma hedefleri, klavye davranışı ve ağ gecikmesi konusunda. Bu farkı birkaç kez acı bir şekilde öğrendiğimden beri kural oldu.
Bu üç katmanlı teslim ilk başta yavaş geliyor. Ama sözleşmeyi öne almak, kuralı tek yerde tutmak ve istemcileri sırayla bitirmek — bu üç alışkanlık, sonradan çıkan “neden burada farklı davranıyor?” hatalarını neredeyse sıfıra indirdi. Yavaş görünen, aslında en hızlı yol oldu.