Expo Updates'i Kendi Sunucunda Barındırmak: SaaS Olmadan OTA

Expo ile geliştirilen bir React Native uygulamasının sessiz süper güçlerinden biri havadan (over-the-air) güncellemelerdir. Bir JavaScript paketi (bundle) değişikliğini, uygulama mağazası inceleme döngüsünden geçmeden kullanıcılara gönderebilirsiniz; bu da bir yazım hatası düzeltmesinin veya küçük bir hatanın insanlara günler yerine dakikalar içinde ulaşması demektir. Etkinlik arkadaşlığı uygulamam Eşlik Et için, o teslim yolu gerçekten kritik. Bu yüzden bazı insanları şaşırtan bir karar verdim: barındırılan (hosted) bir güncelleme servisine güvenmek yerine, bir alt alan adının (subdomain) arkasında oturan bir Next.js servisi olan kendi Expo Updates sunucumu çalıştırıyorum.

Bu varsayılan tavsiye değil ve iyi bir nedenle. Ama bu uygulama için doğru karardı ve nedenleri, ona karşı argüman oluşturan kısımlar da dahil olmak üzere, dürüstçe ortaya koymaya değer.

OTA Güncellemeleri Aslında Nasıl Çalışır

Yüksek düzeyde, havadan güncellemeler uygulamanızın native kabuğu ile çalıştırdığı JavaScript paketi arasındaki bir ayrıma dayanır. Native ikili (binary), uygulama mağazasındaki şey, nadiren değişir. Ürün mantığınızın çoğunun yaşadığı JavaScript paketi sık sık değişebilir. OTA güncellemeleri, yeni bir ikili göndermeden o paketi değiştirmenizi sağlar.

Mekanizma bir manifest'tir. Uygulama başlatıldığında, bir güncelleme sunucusuna şu anda sahip olduğundan daha yeni bir paket olup olmadığını sorar. Sunucu, mevcut güncellemeyi tanımlayan bir güncelleme manifest'i ile yanıt verir ve varsa, uygulama yeni paketi indirir ve bir sonraki başlatmada çalıştırır. Manifest, sunucunuz ile uygulamanızın her kurulu kopyası arasındaki sözleşmedir. O uç noktayı kontrol eden, kullanıcılarınızın hangi kodu çalıştırdığını kontrol eder.

Neden Kendi Sunucumda Barındırmayı Seçtim

O son cümle, tam olarak ona sahip olmak istememin nedeni. Kararı birkaç neden yönlendirdi.

Birincisi, dağıtım (rollout) üzerinde denetim. Bir güncellemeyi kimin tam olarak ne zaman alacağına karar vermek istiyorum ve o mantığı başka birinin gösterge panosunun içinde çalışmak yerine kendim tasarlama özgürlüğünü istiyorum. İkincisi, maliyet. Bir uygulama büyüdükçe, barındırılan güncelleme servisleri kullanıma göre faturalandırır ve sahip olduğum bir yol, zaten ödediğim altyapıda çalışır. Üçüncüsü, veri ikametgâhı (data residency). Güncelleme uç noktası, kullanıcılarımın uygulama sürümleri ve cihazları hakkında bilgi görür ve bunu kendi sınırım içinde tutmanın bir değeri var. Dördüncüsü ve en önemlisi, bağımlılık riski. Güncelleme sunucusu kritik bir teslim yolu. Çökerse düzeltmeleri gönderemem. O tek başarısızlık noktasını tamamen üçüncü bir tarafın eline bırakmaktan rahat değildim.

İmzalama ve Manifest'ler Yanlış Yapamayacağınız Kısım

OTA'yı kendi sunucunuzda barındırmanın en güvenlik açısından hassas parçası imzalamadır. Güncelleme mekanizması kullanıcılarınıza yürütülebilir kod teslim ettiği için, uygulamanın bir güncellemenin gerçekten sizden geldiğini ve aktarım sırasında kurcalanmadığını veya bir taklitçi tarafından sunulmadığını doğrulaması gerekir. Expo, güncelleme manifest'lerini özel bir anahtarla imzalamayı destekler ve uygulama bunları derlemeye gömülü bir genel (public) anahtara karşı doğrular.

Kendi sunucunuzda barındırdığınızda, o anahtar malzemesine siz sahip olursunuz. Bu, eşit ölçüde güç ve yüktür. İmzalama anahtarının denetimini kaybedin ve birisi tüm kullanıcı tabanınıza kötü amaçlı kod sunabilir. Anahtarı tamamen kaybedin ve güvenilir güncellemeleri göndermekte zorlanabilirsiniz. Bu yüzden imzalama anahtarları, herhangi bir üretim sırrıyla aynı ciddiyetle ele alınır: dikkatlice saklanır, asla commit edilmez ve her kurulumun güvenliği ona bağlıymış gibi ele alınır, çünkü öyle.

Aşamalı Dağıtımlar ve Operasyonel Gerçeklik

Sunucuya sahip olmak, aşamalı dağıtımları (staged rollouts) kendi koşullarımda uygulayabileceğim anlamına gelir; yeni bir paketi önce bir kullanıcı dilimine yayar, çökmeleri veya hata sıçramalarını izler ve yalnızca sağlıklı göründüğünde dağıtımı genişletirim. Kötü bir güncellemeyi sınırlama yeteneği, benim için, yola sahip olmanın en güçlü argümanlarından biri.

Ama maliyet konusunda dürüst olmak istiyorum çünkü insanların geçiştirdiği kısım bu. OTA'yı kendi sunucunuzda barındırmak, artık kritik bir altyapı parçası çalıştırdığınız anlamına gelir. Onun çalışma süresine, lansman günü trafiği altında ölçeklenmesine, izlenmesine, anahtar rotasyonuna ve güvenlik yamalarına siz sahipsiniz. O uç nokta yavaş veya çökmüşse, her uygulama açılışı bunu hisseder. Bir sağlayıcının güvenilirlik mühendisliğini kendinizinkiyle takas ettiniz ve o iş gerçekten hiç bitmez. Bu, tek seferlik bir kurulum değil, kalıcı bir operasyonel taahhüttür.

Barındırılanın Daha Akıllı Seçim Olduğu Durumlar

Bu yüzden gösterişsiz şeyi söyleyeceğim: çoğu ekip için, barındırılan güncelleme servisi doğru cevap ve tereddüt etmeden tavsiye ederim. Güncelleme teslimatınız, ara sıra bir sağlayıcıya bağımlı olmanın kabul edilemez olacağı kadar kritik değilse, belirli veri ikametgâhı gereksinimleriniz yoksa ve zamanınızı altyapı çalıştırmak yerine ürüne harcamayı tercih ederseniz, barındırılan kolayca kazanır. İmzalama, dağıtımlar ve güvenilirlik, tam zamanlı işi tam olarak bu olan insanlar tarafından halledilir.

Eşlik Et için kendi sunucumda barındırıyorum çünkü denetim, ölçekte maliyet ve bağımlılık riskinin kombinasyonu bu belirli uygulama için dengeyi değiştirdi ve onunla gelen operasyonel ağırlığı üstlenmeye razıydım. Asıl karar bu. Kendi sunucunuzda barındırmanın zekice olup olmadığı değil, kritik bir teslim yoluna ve onu hayatta tutmakla gelen her şeye gerçekten sahip olmak isteyip istemediğiniz. Çoğu insan için, çoğu zaman, dürüst cevap hayır ve bunda utanılacak bir şey yok.