JavaScript ve TypeScript geliştiricisi — web'i ve mobili aynı API'den besliyorum

Bu ekosistemde ne teslim ediyorum

Ortak noktaları hepsinin aynı sözleşmeye bağlanması; tasarım sistemi kurmuyorum, API ile konuşan arayüzü kuruyorum.

• Üç katman, tek sözleşme

  Aynı özellik REST API, web arayüzü ve mobil uygulama olarak birden çıkıyor. Ayrımı katı tutuyorum: web ile mobil birbiriyle hiç konuşmuyor, yalnızca ortak API üzerinden haberleşiyor.

• Mobil istemci

  React Native ve Expo ile aynı ürünün iOS ve Android karşılığı. Mağazaya gönderme süreci de bu işin parçası.

• Tip katmanı

  TypeScript API'den arayüze tek sözleşme taşıyor. Sözleşmeyi iki uçta ayrı ayrı yazmak, sözleşmenin olmaması demek.

• Derleme ve stil hattı

  Geliştirme sunucusunu saniyelere indiren derleme hattı ve utility-first stil katmanı. Araç zinciri değişiyor, bu iki katmanın işi aynı kalıyor.

Zor kısım kod değil, sözleşme

Arayüz tarafında karşılaştığım hataların çoğu arayüz hatası gibi görünüp sözleşme hatası çıkıyor. Bir alanın adı, bir tarihin biçimi ya da bir hata kodunun anlamı katmanlar arasında ayrıştığında sonuç, hepsi ayrı görünen ama aynı kökten gelen bir hata kümesi oluyor. Bu yüzden işe arayüzün nasıl görüneceğinden değil, arka ucun ne söz verdiğinden başlıyorum.

Tek bir kütüphaneye bağlı değilim

Üçü de aynı sorunun farklı cevabı; hangisinin açılacağına ürünün ihtiyacı karar veriyor.

• Vue tarafı

  Uzun süre burada çalıştım: bileşen tabanlı arayüz mimarisi, yönlendirme ve durum yönetimi. Kaybolmuş bir yatırım değil — iki yaklaşımı karşılaştırabildiğim yer orası.

• React tarafı

  Ağırlık merkezinin buraya kayması mobil ihtiyaçla oldu; aynı zihinsel modelin web ve mobilde birlikte durması işleri kolaylaştırdı.

• Sunucu tarafı framework'ten çıkan arayüz

  Modern bir arayüzü sunucu tarafı framework'ün içinden çıkaran ve tarayıcıya inen kodu azaltan yaklaşımlar.

Bir aracı neye göre değiştiriyorum

Bu ekosistemde en uzun süredir izlediğim şey araçların değişmesi — jQuery ile AJAX'tan Gulp'a, Webpack'e, Vite'a. Karar her seferinde aynı sıradan geçti.

01 Ödenen bedel her zaman yapılandırma

Her geçişte ödediğim şey aynıydı: yapılandırma. Aracın kendisi değil, onu çalışır hâle getiren ayar yükü pahalı olan.

02 Geri dönüş bedelden büyük olmalı

Yeni bir aracı, ödediğim yapılandırma bedelinden fazlasını geri veriyorsa alıyorum. Vermiyorsa eski araç yerinde kalıyor.

03 "Daha modern" bir gerekçe değil

Aracın yaşı bir ölçü değil. Ölçü, o aracın bu üründe hangi somut işi ucuzlattığı.

04 Build süresi de bir kalem

Aynı ölçüyü derleyici tarafında da uyguluyorum: build süresi bir maliyet kalemi, bir ayrıntı değil.

Mobil tarafta kendi kurallarını dayatanlar

Web'deki React deneyiminin transfer olacağı beklentim kısmen doğru çıktı: bileşen düşüncesi aynı, geri kalanı değil.

• Gezinme mimarisi

  Ekran mimarisiyle birlikte kurulan gezinme; web'deki router alışkanlığı buraya olduğu gibi taşınmıyor.

• Liste render performansı

  Uzun listelerde render performansı, mobil tarafta ayrı ayrı üzerinde çalıştığım başlıklardan biri.

• OTA ile sürüm yönetimi

  Güncellemenin mağaza turuna girmeden dağıtılabilmesi, sürüm yönetimini kendi başına bir konu hâline getiriyor.

• Mağaza teslimi

  Gönderim sürecinin kendisi de bu işin parçası — ve uygulamanın kodundan bağımsız bir zanaat.

Neyi yapmıyorum

Erişilebilirlik denetimi, tasarım sistemi kurma ve ileri düzey animasyon işleri benim uzmanlık alanım değil; bunu söylemem gerektiğinde söylüyorum. Arayüz mimarisinin sistem tarafına değen kısımlarını — SSR kararları, önbellek stratejisi — yazdığım yer ise sade.dev.