Kısım II · İnşaat · Bölüm 22

Uygulama Türleri

Web, mobil ve masaüstü; her birinin parçaları (Kinds of applications: web, mobile, desktop)

1. Kat 10Bizim uygulamamızHukuk dersleri, puan, seri, leaderboard. Bu bölümde uygulamamızın türünü seçiyoruz.
2. Kat 9Web ve tarayıcı: HTML, CSS, JavaScriptTarayıcı denen programın anladığı diller: iskelet, görünüm, davranış. Web uygulamasının zemini. Bölüm 20, 23–26.
3. Kat 8Ağ ve internetBilgisayarların birbirine bit göndermesi; IP, TCP, DNS, HTTP. Bölüm 19–20.
4. Kat 7İşletim sistemi (macOS, Windows, Linux)Donanımın idaresi: programlara işlemci zamanı, bellek ve dosya dağıtır. Bölüm 13–18.
5. Kat 6Gömülü yazılım (firmware) ve açılışDüğmeye basınca ilk çalışan program; işletim sistemini başlatır. Bölüm 12.
6. Kat 5Programlama dilleri ve derleyiciİnsanın okuyabildiği kodu (C, Go, JavaScript) makine diline çeviren araçlar. Bölüm 9–11, 21.
7. Kat 4Makine dili ve assemblyİşlemcinin doğrudan anladığı, bitlerden oluşan komutlar. Bölüm 7.
8. Kat 3İşlemci ve bellek (CPU, RAM)Komutları tek tek getirip çalıştıran makine ve verinin durduğu yer. Bölüm 6, 8.
9. Kat 2Devreler: hesap ve hafızaKapılardan kurulan toplayıcılar ve hatırlayan devreler. Bölüm 4–5.
10. Kat 1Transistör ve mantık kapılarıElektrikle açılıp kapanan anahtarlar. Bölüm 3.
11. Kat 0Elektrik ve bit (zemin)Var ya da yok, 1 ya da 0. Bölüm 2.

Bölüm 21'de dillerin haritasını çıkardık ve hangi dilin hangi katta çalıştığını gördük. Şimdi bir adım geri çekilip ürünün kendisine bakıyoruz: "Hukuk-Duolingo" dediğimizde tam olarak ne yapıyoruz? Bir web sitesi mi, telefona yüklenen bir uygulama mı, bilgisayar programı mı? Bu bölümün sonunda uygulama türlerini (web, mobil, masaüstü) birbirinden ayırabilecek, her türün içinde hangi parçaların bulunduğunu söyleyebilecek ve bizim uygulamamızın bu haritada nereye oturduğunu açıklayabileceksin. Bu bir sınıflandırma bölümü; yeni bir dil öğrenmiyoruz, sonraki bölümlerin (özellikle 23–26 ve 32) neden öyle olduğunu anlayabilmek için zemini kuruyoruz.

22.1 Web uygulaması: web sitesi ile web uygulaması farkı

Önce kelimeye dikkat: bu kitapta "uygulama" yalnızca application demektir (Sözlük'teki karar). Bir web uygulaması (web application), tarayıcının içinde çalışan bir uygulamadır: kullanıcı bir adres yazar ya da bir bağlantıya tıklar; ekrana gelen şey bir belge değil, kendisiyle etkileşilen bir programdır. Bir web sitesi (website) ise ağırlıklı olarak okunacak içerikten oluşur: bir haber yazısı, bir kanun metni, bir firma tanıtım sayfası.

Sınır keskin değildir; bir cetvel gibi düşün. Cetvelin bir ucunda statik bir site var. MDN'in sunucu tarafı derslerindeki tarife göre statik site (static site), belirli bir kaynak istendiğinde sunucunun her seferinde aynı, önceden yazılmış içeriği döndürdüğü sitedir: /urun1.html sayfası her kullanıcıya aynı gelir; yeni ürün eklemek için yeni bir dosya yazarsın.¹ Cetvelin diğer ucunda dinamik site (dynamic site) var: içeriği, istenen adrese ve veriye göre üretip döndüren site. MDN örneği: ürün verisini bir veritabanında tutan sunucu, istek gelince sayfayı o veriyle oluşturur.¹ MDN sunucu tarafı kodun en büyük yararını şöyle özetler: içeriği her kullanıcı için ayrı ayrı uyarlayabilmek.¹

Web uygulaması bu cetvelin dinamik ucunda, bir adım ötededir: yalnızca içerik üretmez, kullanıcıyla konuşur. Soruya cevap verirsin, puanın değişir, seri artar, leaderboard'daki yerin kayar. Bunun tarayıcıdaki işini JavaScript yapar (bu kitabın 25–26. bölümleri). Üç ölçüt işine yarar:

• Etkileşim: kullanıcı yalnızca okuyor mu, yoksa veri giriyor ve sonuç görüyor mu?
• Durum: sayfa "kim olduğunu" ve "nerede kaldığını" hatırlıyor mu? (Durumu Bölüm 26.3'te ayrıntılı göreceğiz.)
• Veri: içerik önceden yazılmış dosyalardan mı geliyor, yoksa bir sunucudan ve veritabanından canlı mı?

Tek sayfa uygulama

Klasik web sitelerinde bir bağlantıya tıkladığında tarayıcı yeni bir HTML belgesi ister ve sayfanın tamamı yeniden yüklenir (Bölüm 20'deki istek–yanıt turu). Tek sayfa uygulama (SPA, single-page application) bu düzeni değiştirir. MDN'in tarifiyle SPA, yalnızca tek bir web belgesi yükleyen ve başka içerik gösterilmesi gerektiğinde bu belgenin gövdesini fetch gibi JavaScript API'leriyle güncelleyen bir web uygulaması gerçeklemesidir.² Yani adres çubuğundaki ya da ekrandaki bölüm değişse bile tarayıcı yeni sayfa istemez; JavaScript sunucudan yalnızca veriyi ister ve ekranı kendisi günceller.

Bunun yararı hız ve akıcılıktır: sayfa yanıp sönmez, yalnızca değişen kısım güncellenir. MDN bunu "performans kazanımı ve daha dinamik bir deneyim" diye anar, ama dengeyi de söyler: arama motoru uyumu (SEO), durumu yönetmek için gereken ek çaba, gezinmeyi (navigasyonu) gerçeklemek ve performansı anlamlı biçimde izlemek bedeli olarak gelir.² Bir benzetme: her sayfada yeni bir kitap açmak yerine, aynı kitabın içinde yaprak çevirmek. Yapraklar hızlı döner; ama kitabın içindekileri sen yönetirsin.

22.2 Mobil: yerel, çapraz platform, PWA; APK ve uygulama mağazaları

Telefonda çalışan bir uygulamayı üç farklı yoldan yapabilirsin. Üçünü ayıran şey, kodun kimin diliyle yazıldığı ve ekrandaki şeyleri kimin çizdiği.

Yerel uygulama

MDN'in tanımıyla yerel uygulama (native application), hedeflenen donanım–yazılım ortamı için derlenmiş uygulamadır; MDN'in örneği, Android araç zinciriyle yazılmış bir mobil uygulama; bir tarayıcının içinde çalışan web uygulaması ise yerel değildir, çünkü tarayıcı yerel ortamın üstünde durur.³ Bu, Bölüm 21'deki dil haritasının doğrudan karşılığı: Android için Kotlin (ya da Java, C++) ve Android'in resmî geliştirici araçları (SDK); Android belgeleri, SDK araçlarının kodunu veri ve kaynak dosyalarla birlikte bir APK ya da Android App Bundle'a derlediğini söyler.⁴ Apple tarafında Swift, Apple'ın deyişiyle "tüm Apple platformları için" dil.⁵ Yerel uygulamanın artıları, MDN'in genel çerçevesiyle: cihazda kendi simgesi, çevrimdışı ve arka planda çalışabilmesi, kendine özgü kullanıcı arayüzü ve işletim sistemine derin entegrasyon (paylaşma menüsüne eklenmek gibi).⁶ Eksisi: iki ayrı dünya. Android ve iPhone için iki ayrı dil, iki ayrı kod tabanı, iki ayrı ekip.

Çapraz platform

Çapraz platform (cross-platform) yaklaşım, tek kod tabanından birden çok platforma uygulama üretmeyi hedefler. İki tanınmış yol:

• React Native: resmî sitesine göre React ile Android, iOS ve diğer platformlar için yerel uygulama oluşturur; "JavaScript ile yazılır, yerel kodla çizilir": React'in ilkelleri platformun kendi yerel kullanıcı arayüzü yapı taşlarına dönüşür, yani uygulaman diğer uygulamalarla aynı yerel platform API'lerini kullanır.⁷ Belgeler bunu şöyle açıklar: Android ve iOS'ta ekranın temel yapı taşı bir görünümdür (view); Android'de bunları Kotlin ya da Java'yla, iOS'ta Swift ya da Objective-C'yle yazarsın; React Native'de ise bunları JavaScript'ten çağırırsın ve çalışma sırasında karşılık gelen yerel görünümler yaratılır.⁷ Burada kritik fark şu: tarayıcı yok. Ekrandaki düğme bir HTML düğmesi değil, telefonun kendi düğmesi.
• Expo: React Native üstünde bir çerçeve. Belgelerine göre Android ve iOS uygulamalarını geliştirmeyi kolaylaştırır; dosya tabanlı yönlendirme, yerel modüllerden oluşan standart bir kütüphane ve daha fazlasını sunar.⁸ Ana sayfasındaki söz: "tüm kullanıcılarının cihazlarında yerel olarak çalışan tek bir JavaScript/TypeScript projesi kur"; ayrıca evrensel (Android, iOS ve web) bir uygulama kurmaktan ve uygulama mağazalarına yayından söz eder.⁹ Bizim seçimimiz bu. Bölüm 32 ayrıntılı işler.
• Flutter: başka bir çapraz platform çözümü: tek kod tabanından çok platformlu uygulamalar; arayüzde her şeyin bir widget olduğu bir yapı, dili Dart.¹⁰ Bizim yığınımızda yok; adını bilmen yeter.

İlerlemeli web uygulaması (PWA)

Üçüncü yol ayrı bir uygulama yazmak yerine web uygulamasını telefona "uygulama gibi" yüklemek. MDN'e göre ilerlemeli web uygulaması (PWA, progressive web app), web platformu teknolojileriyle kurulmuş ama platforma özgü bir uygulamanın kullanıcı deneyimini sunan uygulamadır. Web sitesi gibi tek bir kod tabanından birçok işletim sistemi ve cihazda çalışır ve doğrudan web'den erişilir; platforma özgü uygulama gibi cihaza yüklenebilir, ana ekranda simgesi olur, tarayıcı çerçevesi olmadan tek başına açılır, çevrimdışı ve arka planda çalışabilir, bildirim gösterebilir.⁶ Ayrıca PWA'lar uygulama mağazalarından da dağıtılabilir ve doğrudan web'den de yüklenebilir.⁶ Yani PWA, web uygulaması ile mobil uygulama arasında bir köprüdür.

Uygulama paketi: APK, AAB ve mağazalar

Telefona bir uygulama nasıl yüklenir? Yerel (ve Expo ile üretilen) bir uygulama bir paket dosyası olarak dağıtılır. Android'de bu paket APK (Android package): Android belgelerinin tarifiyle .apk uzantılı, uygulamanın çalışma zamanında gereken her şeyini içeren ve Android cihazların uygulamayı yüklemek için kullandığı arşiv dosyasıdır. Yanında .aab uzantılı Android App Bundle vardır: bu bir yayın biçimidir, cihaza doğrudan yüklenemez; APK üretimi ve imzalama sonraki aşamaya bırakılır. Google Play üzerinden dağıtımda Play'in sunucuları, istek yapan cihaza özel olarak yalnızca gereken kaynak ve kodu içeren optimize APK'lar üretir.⁴ Her Android uygulaması kendi güvenlik kum havuzunda (sandbox) yaşar.⁴ Apple tarafında benzer rolü App Store oynar.¹¹

Uygulama mağazası (app store), MDN'in tarifiyle platforma özgü uygulamaların genellikle dağıtıldığı yerdir: kullanıcı orada uygulamayı bulur, yükler ve sonrasında uygulama cihazının kalıcı bir özelliği gibi görünür.⁶ Web'in aksine, mağazadan dağıtım bir aracıdan geçmek demektir: yayından önce yüklemen, mağazanın kurallarına uyman gerekir. Expo'nun derleme servisi (EAS Build) tam bu uçtaki işi, yani kaynaktan mağazaya giden yolu otomatikleştirir.¹² Bu zinciri Bölüm 43'te yayına alma konusunda göreceğiz.

22.3 Masaüstü: yerel uygulamalar ve Electron

Bilgisayarında (macOS, Windows, Linux) çalışan uygulamalar iki gruba ayrılır. Masaüstü yerel uygulama (native desktop application) işletim sistemi için derlenmiş programdır (Bölüm 13'teki işletim sistemi, programlara pencere, dosya, bellek sağlıyordu; yerel uygulama bu hizmetleri doğrudan kullanır). Hızlıdır ve işletim sistemiyle derin bütünleşir; ama genellikle her işletim sistemi için ayrı yazılması gerekir: Windows'a, macOS'a, Linux'a ayrı sürümler.

İkinci grup, web teknolojisiyle yazılıp masaüstü uygulaması gibi paketlenenlerdir. En bilineni Electron. Resmî tarifi: JavaScript, HTML ve CSS kullanarak masaüstü uygulaması yapmak için bir çerçeve; ikilisine Chromium ve Node.js'i gömerek tek bir JavaScript kod tabanından Windows, macOS ve Linux'ta çalışan uygulamalar kurmanı sağlar.¹³ Yani bir Electron uygulaması aslında kendi küçük tarayıcısını paketin içinde taşıyan bir web uygulamasıdır. Belgeleri, her Electron uygulamasında bir ana süreç (main process: Node.js ortamında çalışan, pencereleri yaratıp yöneten giriş noktası) ve pencere içeriğini çizen çizim süreçleri (renderer) olduğunu açıklar;¹⁴ süreç kavramını Bölüm 14'te görmüştün. Bedeli doğal olarak büyüklüktür: her uygulama kendi tarayıcı motorunu içinde taşır.

Bölüm 21'deki harita burada da çalışır: yerel masaüstü için C++, C#, Swift gibi diller; Electron için JavaScript/TypeScript. Bizim projemizde masaüstü uygulaması hedef değil; Expo bize web desteği veriyor, tarayıcıdan zaten bir bilgisayardan kullanılabilir. Ama bir gün "masaüstü sürümü istesek?" sorusu gelirse seçeneklerin Electron ya da yerel uygulama olduğunu, ve web kodumuzu Electron'a taşımanın ikincisinden çok daha kısa bir yol olduğunu bilirsin.

22.4 Her türde istemci ve sunucu parçaları

Bölüm 19.6'da istemci–sunucu modelinin ilk tanımını gördün: bir taraf istek gönderir (istemci), diğer taraf cevap verir (sunucu). Bu ayrım üç uygulama türünün hepsinde aynıdır; değişen, istemcinin ne olduğu. MDN'in tarifiyle web tarayıcıları web sunucularıyla HTTP üzerinden konuşur; bir bağlantıya tıkladığında, form gönderdiğinde ya da arama yaptığında tarayıcıdan hedef sunucuya bir HTTP isteği gider; sunucu bunu işler ve bir HTTP yanıtıyla cevaplar.¹ Bir mobil uygulamada da aynıdır, yalnızca istemci artık tarayıcı değil, telefonda çalışan uygulamanın kendisidir.

   İSTEMCİ (kullanıcının cihazı)                 SUNUCU (bizim bilgisayarımız)
 ┌─────────────────────────────────┐          ┌──────────────────────────────┐
 │ Web:     tarayıcı + HTML/CSS/JS │          │ Go programı (API)            │
 │ Mobil:   Expo uygulaması        │ ◄─HTTP─► │   ├ kuralları uygular        │
 │ Masaüstü: Electron / yerel      │  (istek, │   └ veriyi okur ve yazar     │
 │                                 │  yanıt)  │ Postgres, Redis (veri, önb.) │
 └─────────────────────────────────┘          └──────────────────────────────┘
   görünen, dokunulan, hızlı tepki              ortak, güvenilen, kalıcı veri

İki taraf arasındaki işbölümü şu soruya dayanır: hangi kod kimin elinde çalışmalı? İstemci kullanıcının cihazındadır; kullanıcı onu inceleyebilir, değiştirebilir. Sunucu bizim bilgisayarımızdır. Bu yüzden iki ilke doğar:

• Görünüm ve anlık tepki istemcide. Düğmeye basınca rengin değişmesi için sunucuya gitmeye gerek yok; telefondaki kod bunu anında yapar.
• Gerçek veri ve kurallar sunucuda. Puanın doğru hesaplandığına, leaderboard'un herkes için aynı olduğuna güvenmek istiyorsak, bunların son sözü sunucuda olmalı. "Kullanıcı cevabı doğru mu girdi?" kararının istemcide verilmesi bir hileye açıktır, çünkü istemci kullanıcının kontrolündedir. Bunu Bölüm 41'de güvenlik başlığı altında ele alacağız.

Üçünde de sunucu aynı olabilir. Bu önemli bir mimari kazanımdır: tek bir arka uç, web'e de iOS'a da Android'e de aynı cevapları verir; ön yüzler değişebilir, veri ve kurallar aynı kalır. İstemci ile sunucunun konuşma biçimi (API) Bölüm 34–35'in konusu. Not: bir tarayıcı uygulaması, statik dosyaları da sunucudan alır; "web sunucusu" önce HTML, CSS, JavaScript dosyalarını verir (siteyi yükleyen kısım), sonra uygulama bu sayfanın içinden veri istemeye devam eder. MDN'in belirttiği gibi dinamik sitelerde statik dosya isteği (CSS, JavaScript, resim) tamamen aynı biçimde karşılanır.¹

22.5 Uygulamamızın türü: web + mobil (Expo) + Go arka uç

Şimdi kendi uygulamamızı haritaya yerleştirelim. Plan: mobil uygulama (Expo, TypeScript), web sürümü ve Go arka uç. Kararın arkasındaki mantık, bu bölümün üç kavramıyla okunur:

1. Neden mobil? Duolingo benzeri bir uygulamanın doğal yeri telefon: kısa, sık, günlük kullanım; "seri" (streak) alışkanlığı, bildirimler, çevrimdışı bile çalışabilme. PWA bunların bir kısmını verir, ama yerel mağaza uygulaması kullanıcının "uygulama" beklentisine en yakın şeydir.
2. Neden çapraz platform (Expo)? İki ayrı yerel uygulama (Android için Kotlin, iPhone için Swift) iki ayrı ekip ve iki ayrı kod tabanı demek. Expo, Android, iOS ve web'i tek TypeScript projesinden hedeflemeyi vadediyor.⁹ Küçük bir ekip ve büyük ölçüde agent'larla yazılan bir kod tabanı için tek kod tabanı çok daha yönetilebilir.
3. Neden ayrı bir Go arka uç? Mobil uygulama, web uygulaması ve belki ileride başka istemciler aynı veriyi paylaşacak: puanlar, seriler, leaderboard. Bunların tek bir güvenilir yerde yaşaması gerekiyor (22.4). Bu "yer", Bölüm 34'te kuracağımız sunucu.

Bu bölümde neler kuruldu

Uygulamalar üç ana türdedir. Web uygulaması tarayıcıda çalışır; web sitesi ağırlıklı olarak içeriktir, web uygulaması etkileşimlidir; tek sayfa uygulama (SPA) tek belge yükleyip içeriği JavaScript ile güncelleyen web uygulamasıdır. Mobil uygulama üç yolla yapılır: yerel (Kotlin/Swift, platform araçlarıyla, her platform için ayrı), çapraz platform (React Native/Expo: tek TypeScript projesi, yerel arayüzle çizilir; Flutter ayrı bir seçenek) ve PWA (yüklenebilir web uygulaması). Android uygulaması APK ya da AAB olarak paketlenir ve uygulama mağazaları aracılığıyla dağıtılır. Masaüstü uygulaması yerel olabilir ya da Electron ile (içine Chromium ve Node.js gömülü bir web uygulaması olarak) yapılabilir. Her türde istemci kullanıcının cihazındaki kodu, sunucu ortak ve güvenilir veriyi tutan kodu anlatır; görünüm ve anlık tepki istemcide, gerçek veri ve kurallar sunucuda olur. Bizim uygulamamız: Expo ile mobil (ve web), Go arka uç; bugünkü prototip ise tarayıcıda çalışan bir web uygulaması.

Terimler sözlükte, Bölüm 22 başlığı altında.

Kaynaklar

1. MDN, Introduction to the server side ve Client-Server overview: statik ve dinamik siteler, HTTP isteği ve yanıtı.
2. MDN, Glossary: SPA (Single-page application).
3. MDN, Glossary: Native.
4. Android Developers, Application fundamentals: APK, Android App Bundle, Google Play, uygulama sandbox'ı.
5. Apple Developer, Swift: Swift'in tüm Apple platformları için dil olarak tanımı.
6. MDN, What is a progressive web app?: platforma özgü uygulamalar, web siteleri ve PWA'lar.
7. React Native, Core Components and Native Components ve ana sayfa: JavaScript ile yazılıp yerel kodla çizilme.
8. Expo, Create a project: Expo'nun React Native çerçevesi olarak tanımı.
9. Expo, Expo documentation: tek JavaScript/TypeScript projesi, evrensel Android, iOS ve web uygulaması.
10. Flutter, Flutter documentation: tek kod tabanından çok platformlu uygulamalar.
11. Apple Developer, App Store.
12. Expo, EAS Build: derlemeden uygulama mağazalarına yayına giden yol.
13. Electron, Introduction: Chromium ve Node.js gömme.
14. Electron, Process Model: ana süreç ve çizim süreçleri.