Bir uygulama gerçekte nasıl çalışır

Bir düğmeye dokunduğunuzda ne olur?

Tek bir dokunuş art arda dört iş başlatır. Önce arayüz kodu ekranın neresine dokunulduğunu ve bu dokunuşun hangi düğmeye ait olduğunu çözer. Sonra uygulama mantığı bu düğmenin hangi veriye ihtiyacı olduğuna ve verinin o an cihazda bulunup bulunmadığına karar verir. Yoksa bir HTTPS isteği sunucuya gider. En sonunda geri gelen şey ekrana dönüşür.

Bu dördünün üçü saniyenin binde birkaçında biter. Üçüncüsü bitmez. Sunucuya gidiş dönüş neredeyse her zaman en uzun bölümdür ve bir kez kendiniz ölçtüğünüzde bir daha unutmazsınız. Bu komut, tam da bu sitenin API sine tek bir istek gönderir ve aşamalarını ayrı ayrı yazdırır:

curl -s -o /dev/null -w 'dns=%{time_namelookup} tls=%{time_appconnect} first_byte=%{time_starttransfer} bytes=%{size_download}\n' "https://rgb.ir/wp-json/wp/v2/posts?per_page=1&_fields=id,title,link,date"

Art arda üç kez çalıştırdık. Alan adının çözülmesi saniyenin 1,4 ile 4,2 binde biri arasında sürdü, güvenli TLS el sıkışması 31 ile 49 binde bir arasında tamamlandı ve yanıtın ilk baytı 167 ile 194 binde bir arasında geldi. Geri gelen her şey 353 bayttı. Birkaç saat sonra aynı komutu yeniden aldık ve bu kez ilk bayt 180 ile 251 binde bir arasında geldi, yanıtın boyutu ise tam olarak 353 bayt kaldı. Akılda tutulmaya değer sayı 353, süreler değil.

Oranlara bakın. Güvenli bağlantıyı kurmak zamanın yaklaşık dörtte birini aldı, geri kalanı sunucunun yanıtı hazırlamak için harcadığı süredir. Bunların hepsi boyunca uygulama beklemekten başka hiçbir şey yapmadı. Kullanıcının programın yavaş olduğunu söylediği ve geliştiricinin arayüz iyileştirmesi aramaya gittiği yer tam burasıdır.

Bir uygulama hangi katmanlardan kurulur?

Beş katman ve ikisinin arasına düşen sınır, katmanların kendisinden daha önemli. Kullanıcı arayüzü görülen ve dokunulan şeydir: düğmeler, listeler, formlar. Uygulama mantığı her dokunuşun ne yapacağına ve neyin gösterileceğine karar verir. İkisi de telefonun kendisinde çalışır.

Üçüncü katman API dir: uygulamanın sunucudan hangi adreste ve hangi biçimde veri istediğini, sunucunun da hangi biçimde yanıt verdiğini söyleyen sözleşme. O sözleşmenin öbür yanında arka uç bir sunucuda oturur ve kullanıcının cihazında bulunmaması gereken mantığı çalıştırır: fiyat, stok, yetki, ödeme. Altında da şeyleri saklayan bir veritabanı vardır.

Asıl sınır ikinci ile üçüncü katman arasındadır. Onun üstündeki her şey yalnızca bu tek cihaza aittir; altındaki her şey bütün kullanıcılar arasında ortaktır. Bir uygulama projesinde çıkan bütün zor sorular sonunda tek bir soruya iner: bu iş sınırın üstünde mi yoksa altında mı yapılmalı. Yanıtı yanlış verirseniz müşteri fiyatı kendi telefonunda değiştirir.

Yukarıdaki katmanlama bir öğrenme sırasıdır, standart değil ve adlar ekipten ekibe değişir. Değişmeyen şey o sınırdır.

Native, web ve hibrit üç ayrı şeydir

Bir müşteri uygulama istediğini söylediğinde neredeyse her zaman telefon ekranındaki bir simgeyi kastediyordur. Bu simgeyi size tamamen farklı üç teknoloji verir ve aralarındaki fark ancak ağ kesildiğinde ya da yeni bir sürüm göndermeniz gerektiğinde ortaya çıkar.

Native, o işletim sistemi için derlenen ve bir paket olarak kurulan program demektir. Android in kendi belgeleri bunu tam olarak söylüyor: Android uygulamaları Kotlin, Java ve C++ ile yazılır ve SDK araçları kodu ve kaynakları bir APK ya da App Bundle içinde derler; APK, cihazın uygulamayı kurmak için kullandığı dosyadır, App Bundle ise bir cihaza hiç kurulamaz çünkü kurulum biçimi değil yayın biçimidir. Bu tek cümle ilerleyen zamanda, yayın aşamasında işinize yarar.

Web, tarayıcıda açılan şeydir. Hiçbir şey kurulmaz, güncelleme yayınlandığı anda herkese ulaşır ve telefon donanımına erişim sınırlıdır. PWA ise bunun, MDN in tanımıyla, web platformu teknolojileriyle kurulan ama platforma özgü bir uygulama gibi deneyim veren sürümüdür: bir web sitesi gibi tek kod tabanından birçok platformda çalışır, kurulu bir uygulama gibi de cihaza kurulabilir, çevrimdışı ve arka planda çalışabilir ve cihazla bütünleşebilir.

Hibrit, native bir kabuğun içine paketlenmiş bir web uygulaması demektir. Dışarıdan native görünür, içeriden webdir. Formlar ve içerik için iyi çalışır; ağır animasyon ya da kamera ve sensörlerle sürekli çalışma olan her yerde tavanını gösterir.

Duruşumuz basit: bu üçü arasında seçim yapmak bir teknoloji kararı değil, kullanıcınızın programı kullanırken içinde bulunduğu duruma dair bir karardır. Kapsama alanı olmayan bir depoda çalışan biriyle ofiste wi-fi başında oturan biri iki farklı yanıt alır.

Telefonda ne kalır, sunucuda ne yaşar?

İki kural işi bitirir. İki kişinin aynı biçimde görmesi gereken her şey sunucuda kalır: fiyat, stok, sipariş, mesaj. Kullanıcının bağlantı olmadan da görebilmesi gereken her şeyin cihazda bir kopyası olmalıdır: ayarlar, taslaklar, en son baktığı liste ve her seferinde parola yazmasını önleyen oturum işareti.

Token denen o oturum işareti hassas noktadır. Cihazda durduğu sürece kullanıcı oturumda kalır, kolaylık da budur. Telefon kaybolursa token de onunla kaybolur, dolayısıyla sunucu tarafından iptal edilebilir olması gerekir. Bunu yalnızca arka uç yapabilir ve telefondaki hiçbir kod miktarı onun yerini tutmaz.

Çevrimdışı çalışma konusunda sevilmeyen bir söz de var. Çevrimdışı kip isteyen projelerin çoğu aslında kullanıcının asansörde kapsama yokken hata ekranı görmemesini istiyor. İhtiyaçları olan şey bir okuma önbelleğidir ve ucuzdur. Gerçek çevrimdışı, kullanıcının bağlantısız da bir şeyi değiştirebilmesi demektir; o zaman da iki kişi aynı şeyi aynı anda değiştirdiğinde kimin kazanacağına karar vermeniz gerekir. Bu karar pahalıdır ve ihtiyacı olmayan bir proje onu satın almamalıdır.

Uygulamanız neden tam olarak API si kadar hızlıdır

Sıradan bir liste ekranı on satır gösterir. Bu sitenin kendi API sinden on makale istedik: bir kez varsayılan biçimde, bir kez de yalnızca dört alana ihtiyacımız olduğunu söyleyerek:

curl -s -o /dev/null -w '%{size_download}\n' "https://rgb.ir/wp-json/wp/v2/posts?per_page=10"
curl -s -o /dev/null -w '%{size_download}\n' "https://rgb.ir/wp-json/wp/v2/posts?per_page=10&_fields=id,title,link,date"

İlk yanıt 403.152 bayt, ikincisi 3.780 bayttı. Tek bir makale için aynı ikili 37.341 bayta karşı 353 bayt oluyor. Art arda beş örnek aldık ve boyutlar birebir aynı kaldı; süreler kalmadı ve o beş çalıştırmadan biri bu canlı sunucuda 5,3 saniye sürdü. Bu fark başlı başına bir ders: boyut öngörülebilir, süre değil.

Uygulama tarafında hiçbir şey değişmedi. Liste ekranı yüz kat hafifledi, çünkü istek neye ihtiyacı olduğunu söyledi. O 403 kilobaytın geri kalanı makalelerin tam olarak işlenmiş metniydi ve bir liste ekranı onu asla göstermez.

Aynı ölçüm bir şey daha taşıyordu. API yanıtları x-flying-press-cache: MISS ve cf-cache-status: DYNAMIC başlıklarıyla geldi; yani bu sitenin HTML sayfalarının aksine bu yanıtların hiçbiri önbelleğe alınmıyor ve her dokunuş tam bir PHP çalıştırması. Bir web ziyaretçisine rahatça yanıt veren sunucu, bir uygulamanın altında başka türden bir iş yapıyor.

Yani işin doğru sırası şu: çerçeve seçmeden önce API nizin ne döndürdüğüne bakın. Bu yolun bir sonraki dersi tam da o seçimi, native mi cross platform mu sorusunu ele alıyor ve uygulama geliştirme yolu sayfasındaki ders listesinden erişilebilir. Aynı sözleşmenin web tarafından nasıl göründüğünü görmek isterseniz, API nedir dersi onu temelden açıyor.