Uygulama arka ucu nedir

Arka uç nedir ve uygulamanın yarısı neden orada?

Arka uç, kullanıcının hiç görmediği yarıdır ve o olmadan uygulama yalnızca bir fotoğraf albümüdür. Birkaç kişi arasında paylaşılması, uygulama silindikten sonra da kalması ya da kullanıcının kendi elinde olmaması gereken her şey orada yaşar, telefonda değil.

Tek bir örnek her tanımdan açıktır: bir dükkanın sipariş listesi. Bu liste telefonda saklanırsa telefon değişince kaybolur, aynı kişinin tabletinde görünmez ve uygulama dosyalarını açan biri sayıları değiştirebilir. Bu üç cümle, arka ucun var olma sebebinin tamamıdır.

Telefondaki uygulama pratikte üç şey yapar. Ekranı kurar, kullanıcı girdisini alır ve bir istek gönderir. Karar vermek onun işi değildir. Bu bariz görünür ve yeni projelerde ilk çiğnenen kuraldır: indirimi uygulama hesaplar ve son tutarı gönderir, sonra da aynı isteği herkesin istediği sayıyla gönderebildiği anlaşılır.

Dürüst bölüşme şudur: uygulama gösterir, arka uç karar verir. Uygulama nasıl çalışır yazısını okuduysanız, bu aynı sınırın bu kez sunucu tarafından görünüşüdür.

Bir arka ucun içinde ne var?

Arka uç tek bir program değil, her biri tek bir iş yapan ve genelde tek bir sunucuda birlikte duran birkaç parçadır.

İlk parça API, uygulamanın içinden geçtiği kapıdır. Uygulama bir adresi çağırır, veri gönderir ve genellikle JSON olan bir yanıt alır. Her adresin ne beklediği ve ne döndürdüğü, uygulamayla sunucu arasındaki sözleşmedir; API nedir yazısı o sözleşmeyi tam olarak açar.

İkinci parça veritabanıdır. Siparişlerin, kullanıcıların ve mesajların gerçekten yazıldığı ve sunucu yeniden başladıktan sonra da kaldığı yer. Uygulama veritabanına asla doğrudan bağlanmamalıdır; çünkü o zaman veritabanı parolasının uygulamanın içinde yaşaması gerekir ve uygulama dosyasını açan herkes ona sahiptir.

Üçüncü parça oturum servisidir. İşi yalnızca parolanın doğru olup olmadığını söylemek değildir; işi sonraki her isteğe yapışıp bu isteğin hangi kullanıcıdan geldiğini söylemektir. Bu yanıt olmadan sunucunun, az önce kimin sipariş listesinin istendiğini bilmesinin yolu yoktur.

Her zaman geç düşünülen dördüncü parça dosya saklamadır. Profil fotoğrafları ve ekler genelde veritabanının içinde durmaz; kendi yerleri vardır ve veritabanında yalnızca adresleri saklanır. O adresin herkese açık mı yoksa imzalı ve geçici mi olduğu başlı başına bir güvenlik kararıdır.

Bütün bunlar, internet nasıl çalışır yazısında alttan anlatılan şeyin üzerinde çalışır: hiç kapatılmayan ve bir adreste bekleyen bir makine.

Sunucu çöktü dendiğinde tam olarak ne oldu?

"Sunucu çöktü" neredeyse hiçbir zaman bilgisayarın kapandığı anlamına gelmez. Bu tek cümlenin altında tamamen farklı üç durum toplanır ve her birinin çaresi başkadır.

Birincisi: istek sunucuya hiç ulaşmadı. Kullanıcının bağlantısı yoktu, alan adı bir adrese çevrilmedi ya da uygulama o adresi vermeyen bir ağda. Sunucu burada tamamen sağlamdır ve birinin onu aradığından haberi bile yoktur.

İkincisi: sunucu yanıt verdi ve yanıtı bir hataydı. Burada durum kodu önemlidir ve iki ailesi vardır. Beş yüzlü, sorunun sunucu tarafında olduğu; dört yüzlü ise isteğin kendisinin bozuk olduğu anlamına gelir. İkisini de "sunucu çöktü" diye gösteren bir uygulama kullanıcıyı boşuna yorar; 401 tekrar giriş yap, 500 otur ve bekle demektir.

Üçüncüsü, ikisinden de yaygını: sunucu gerçekten yanıt verdi ama çok geç. Aradaki bir şeyin sabrı tükendi ve program hâlâ çalışırken bağlantıyı kesti. Uygulama tarafından bakınca bu, kapalı bir sunucudan ayırt edilemez.

Ekiplerin en çok vakit kaybettiği yer üçüncüsüdür, çünkü sabır sayısı genelde kimsenin bakmadığı bir yerde yazılıdır. PHP nin kendi kılavuzu, request_terminate_timeout ayarını anlatırken bunun "tek bir isteğe hizmet verme süresi olduğunu, sonrasında işçi sürecin öldürüleceğini" söyler ve bu seçeneğin max_execution_time betiğin çalışmasını durdurmadığında kullanılması gerektiğini açıkça ekler. Yani iki ayrı dosyada iki sayı yaşar ve son sözü küçük olan söyler.

Uygulama yazan biri için pratik sonuç: gönderdiğiniz her isteğe açıkça bir zaman aşımı verin, hata yanıtlarını metnine göre değil durum koduna göre ayırın ve her aile için farklı bir davranış yazın. Bu, projenin ilk saatinde on dakika alır; atlanırsa aylar sonra hiçbiri yeniden üretilemeyen "uygulama çalışmıyor" bildirimleri olarak geri döner.

Hazır arka uç mu almalı, kendimiz mi yazmalıyız?

Üçüncü bir yol daha var ve küçük ekiplerin çoğu sonunda oraya varıyor: hizmet olarak arka uç, yani veritabanını, girişi ve dosya saklamayı hazır teslim eden ve hiç sunucu ayağa kaldırmadığınız bir hizmet. Google un Firebase i ve Supabase iki bilinen örnek.

Satın aldığınız şey kendi belgelerinde açıkça yazılı. Firestore güvenlik kurallarının başlangıç sayfası, bu kuralların "altyapıyı yönetmek ya da sunucu tarafı kimlik doğrulama ve yetkilendirme kodu yazmak zorunda kalmadan" harika bir kullanıcı deneyimi kurmaya odaklanmanızı sağladığını söylüyor. Bu tek cümle bütün tasarrufu anlatıyor: normalde haftalar süren iş, tek bir kural dosyasına dönüşüyor.

Karşılığında verdiğiniz şey de aynı sayfalarda ve daha az okunuyor. Aradaki sunucu ortadan kalkınca uygulama doğrudan veritabanıyla konuşur ve verinizle kötü niyetli bir kullanıcı arasında duran tek şey o kural dosyasıdır. Firebase belgeleri bunu tam olarak şu tonda söylüyor: güvenlik kuralları uygulamanızın dışında tanımlanır, dolayısıyla istemciler güvenliği uygulamaktan sorumlu değildir. Bundan çıkan sonucu hatırlayana kadar rahatlatıcı bir cümle: o dosyadaki her hata, başka hiçbir kodun yakalamayacağı bir hatadır.

Aynı sayfalardaki iki küçük not sonradan pahalıya patlıyor. Birincisi, Firestore basit örnek kural setlerini gösterip altına bu kuralların geçerli olduğunu ama üretim uygulamaları için önerilmediğini yazıyor. İkincisi, sunucu istemci kütüphaneleri bütün güvenlik kurallarını atlıyor ve başka bir yoldan doğrulanıyor. Yani kendi sunucunuzda yazdığınız kod, uygulama için yazdığınız kurallardan muaf.

Kilitlenme sorusunu bizden değil onlardan duymak daha iyi. Supabase mimari sayfasında Postgres veritabanını soyutlamadığını ve ona tam yetkiyle eriştiğinizi yazıyor; ilkelerinde ise kilitlenmeyi önlemek için içeri ve dışarı taşınmayı kolay tuttuğunu, bu yüzden pg_dump ve CSV dosyaları gibi mevcut standartları kullandığını söylüyor. Bu, bir üreticinin kendi ürünü hakkındaki iddiası, bizim ölçümümüz değil; ikisinden de gerçek bir göç yürütmedik ve pratikte ne kadar sürdüğünü söyleyemeyiz.

Bizim durduğumuz yer basit. Tek kişinin yazdığı ve gelecek ay birinin telefonunda olması gereken bir uygulama için hazır arka uç doğru seçimdir; kendi kodumuz diye ısrar etmek yalnızca birkaç aylık gecikme satın alır. İçinde para mantığı olan bir ürün içinse, o mantığın kendi sunucunuzda çalışması gereken bir nokta gelir ve bunu yolun ortasında keşfetmektense ilk gün bilmek daha iyidir.

Seçmeden önce kendinize şunları sorun

Arka uç kararı neredeyse hiçbir zaman salt teknik bir karar değildir. Aşağıdaki dört soruyu ciddi ciddi yanıtlayın, cevap kendini gösterir.

Bir: yarın biri, uygulamanızın hiç göndermediği bir istek gönderirse ne olur? Yanıtınız "bizim uygulamamız bunu yapmaz" ise arka ucu henüz düşünmemişsiniz. Uygulamanıza karşı çalışan birinin uygulamanızı kullanma zorunluluğu yok.

İki: hangi sayıları kullanıcı belirlememeli? Fiyat, stok, puan, rol. Bunlardan uygulama tarafından geleni pratikte kullanıcı girdisidir.

Üç: bu hizmeti yarın bıraksanız yanınızda ne gelir? Sağlayıcıya bir suçlama olarak değil, bir alıştırma olarak. Yanıt genelde ürününüzün ne kadarının gerçekten sizin olduğunu gösterir.

Dört: sabahın üçünde sunucuyu kim ayağa kaldırır? Yanıt hiç kimseyse, yönetilen hizmet daha pahalıdır ve ucuz seçenek sayılır.

Ve dördüyle de ilgisi olmayan bir tavsiye: arka ucun ilk satırını yazmadan önce verinin şeklini kağıda çizin. Tablolar ya da koleksiyonlar, alanları ve her satırın kime ait olduğu. Bin kullanıcının verisi girdikten sonra verinin şeklini değiştirmek, projedeki her şeyden pahalıdır. Ekibiniz yoksa ve karar sizden büyüdüyse, RGB uygulama sayfası tam bu aşamayı nasıl ilerlettiğimizi anlatıyor.