Yapay Zeka ile İnşa Ettiğin Uygulamanın Gerçek Bir Backend'e İhtiyacı Var mı? Eklemeden Önce Nasıl Anlarsın

O Merak Etmeye Başladığın An

Backend, tarayıcı dışında bir yerde çalışan koddur — tarayıcının yapmaması gereken şeyleri yapar, para tahsil etmek veya sırları saklamak gibi, ve bir veritabanıyla konuşur. Yapay zeka ile inşa edilen çoğu uygulama, kafanda canlandırdığın şeye benzemese bile bunun bir kısmını zaten yapıyordur.

Uygulaman çalışıyor. Kullanıcılar kaydoluyor. Özellikler yayına giriyor. Sonra içine o sinsi his çöreklenmeye başlıyor: “gerçek bir backend” olması gerekmez mi? Herkes backend’lerden bahsediyor. Ciddi uygulamaların backend’i vardır. Senin builder’ın ise sana React içinde TypeScript gibi bir şey verdi ve şimdi bunun yeterince… profesyonel olmadığını düşünmeye başlıyorsun.

İşte gerçek şu: o his genelde yanılıyor. Bir backend’in yaptığı hiçbir şey sihir değil, ve yapay zeka ile inşa ettiğin uygulama bunu muhtemelen zaten yapıyordur. Yapmıyorsa da, bir backend eklemek gerçek sorunu çözmez — o gerçek sorun her neyse.

Bu yazı, aradaki farkı bilmekle ilgili.

Bir Backend Aslında Ne İçindir?

Bir backend tam olarak üç sebep için var olur: parayla ilgilenmek, sırları güvende tutmak ve birden fazla kişi aynı veriyi düzenlerken tek doğru kaynak olarak davranmak.

Parayla ilgilenmek. Uygulaman ödeme topluyorsa veya kullanıcılara ücret kesiyorsa, ödeme işlemcisi bir backend’i zorunlu kılar. Tarayıcın, gizli API anahtarınla doğrudan Stripe’a istek atamaz (anahtarı istemci tarafı kodda tutmuş olurdun, herkesin görebileceği bir yerde). O yüzden anahtarı güvende tutan, tarayıcıdan gelen istekleri kabul eden ve kullanıcı adına Stripe ile konuşan bir sunucuya ihtiyacın var. İşte bu bir backend. Şatafatlı olmasına gerek yok — çoğu uygulama için tek bir Node fonksiyonu yeterli — ama var olması gerekiyor.

Sırları güvende tutmak. API anahtarları, veritabanı şifreleri, kimlik doğrulama token’ları — bunlar tarayıcıda yaşayamaz çünkü uygulamanı kullanan herkes onları okuyabilir. Yapay zeka ile inşa ettiğin uygulamanın, kimlik doğrulama gerektiren dış bir servisi çağırması gerekiyorsa, tarayıcı bunu tek başına yapamaz. Uygulama, anahtara sahip olan backend’inle konuşabilir, o da dış servisi çağırır. Sırların sır olarak kalır.

Veri için tek doğru kaynak. İki kullanıcı aynı anda uygulamanı kullanıyor ve ikisi de aynı veriyi değiştirmeye çalışıyorsa, hangi değişikliğin kazanacağına karar verecek merkezi bir otoriteye ihtiyacın var. Tarayıcı hakem rolü oynayamaz — iki tarayıcı birbirini göremez. O yüzden “Alice isim değişikliğini kazandı, Bob’unki 30 milisaniye sonra geldi, o yüzden onunki uygulanmıyor” diyecek bir sunucuya ihtiyacın var. O sunucu, bir backend’dir. Veritabanı bölümünün önemli olmasının sebebi de bu — tüm verinin gerçekten yaşadığı tek bir yere ihtiyacın var.

Listede olmayana dikkat et: performans, profesyonellik, ölçeklenebilirlik, “çünkü herkeste var” düşüncesi. Bunlar, ihtiyacın olmayan karmaşıklığı eklemen için seni kandıran hislerdir.

Gerçekten Bir Backend’e İhtiyacın Olduğunu Nasıl Anlarsın?

Üç sinyal, gerçekten bir backend’e ihtiyacın olduğu anlamına gelir: uygulama tarayıcının kendi başına çözemeyeceği bir sebepten yavaş, kullanıcının göremeyeceği veya kesintiye uğratamayacağı bir yerde kod çalıştırman gerekiyor, ya da iki kullanıcı birbirinin verisinin üzerine yazıyor. Hangisinin (varsa) seni ilgilendirdiğini şöyle anlarsın.

“Yavaş.” Kullanıcılar yavaşlıktan şikayet ediyorsa, sorun genelde şu üç şeyden biridir: tarayıcı çok fazla iş yapıyor (CPU’ya bağlı, kötü bir algoritma, çok fazla DOM render ediyor), ağ yavaş (üzücü ama gerçek), veya veritabanı yavaş (çok fazla sorgu, yanlış indeksler — yapay zeka ile inşa ettiğin uygulama zaten bir veritabanıyla konuşuyor, genelde iyi bir tanesiyle). Gerçek bir backend, tarayıcıdaki CPU işini düzeltmez. Gerçek bir backend, ağ gecikmesini düzeltmez (fizikle uğraşmak zor). Bir backend, önbellekleme veya daha akıllı sorgu kalıpları ekleyerek veritabanı sorgularına yardımcı olabilir, ama builder’ın bunu muhtemelen zaten düşünmüştür.

Gerçek bir yavaşlık hikayesi: bir yapılacaklar listesi uygulaması, liste yüklenirken yavaştı. Geliştirici “gerçek bir backend’e ihtiyacım var” diye düşündü. Gerçek sorun: uygulama, ilk 50 tanesini “daha fazla yükle” düğmesiyle yüklemek yerine, her seferinde 5.000 yapılacak işin hepsini yüklüyordu. Backend’e dokunmadan bir öğleden sonrada düzeltildi. Sorun backend değildi.

“Kullanıcının görmemesi gereken kod çalıştırmak istiyorum.” Bu, gerçekten mantıklı olan tek sebep, ve düşündüğünden daha nadir. Örnekler: bir kullanıcı kaydolduktan sonra e-posta göndermek (o kodun, kullanıcı sekmeyi kapatsa bile çalışmasını istersin), dosyaları gece boyunca işleyen bir arka plan işi çalıştırmak, dış bir API’yi belirli bir zamanlamayla çağırmak. Bunlar geçerli sebepler. Bir yerde, bir sunucuda çalışan bir şeye gerçekten ihtiyacın var. Ama bunun kimlik doğrulaması, yönlendirmesi ve veritabanları olan tam bir backend olması gerekmiyor. Belirli bir zamanlamayla çalışan veya bir webhook tarafından çağrılan tek bir “cloud function” olabilir. Tam bir backend’den çok daha basit.

“Birden fazla kullanıcı aynı anda aynı veriyi değiştiriyor ve güncellemeleri kaybediyorum.” Bu gerçek. “Alice’in düzenlemeleri kayboldu” veya “iki kişi aynı formu düzenledi ve ikinci kişinin değişiklikleri birincinin üzerine geçti” görüyorsan, bir çakışma (contention) sorunun var demektir. Bazı veritabanları bunu diğerlerinden daha iyi ele alır, ve bazı yapay zeka builder’ları varsayılan olarak bunu iyi yapmayan veritabanlarını kullanır. Ama çözüm her zaman tam bir backend değildir — veritabanını değiştirmek, kilitleme eklemek, veya iyimser eşzamanlılık kontrolü eklemek olabilir (bir güncellemeye izin vermeden önce eski sürüm numarasını tutup karşılaştırmanın süslü adı). Builder’ına veritabanını değiştirebilir mi veya sürüm takibi ekleyebilir mi diye sor. Bir backend’e değil, daha akıllı bir veritabanı kurulumuna ihtiyacın olabilir.

Backend Sorunu Gibi Görünen Ama Öyle Olmayan Nedir?

Üç şey backend sorunuyla karıştırılır ama değildir: JavaScript’in tek bir yerde yaşaması, ayrı bir API katmanının olmaması, ve belirli bir soruna bağlı olmayan genel bir güvenlik kaygısı.

“Kod JavaScript ve hepsi tek bir yerde.” Pek çok başarılı uygulama, tarayıcıda çalışan JavaScript’tir ve gerçek bir veritabanıyla konuşur (Firebase, Supabase, MongoDB Atlas, builder’ının kurduğu her ne ise). “Gerçek bir backend” sunucusu yoktur. Her şey çalışır. Kodun tek bir dilde, tek bir yerde olması, onu gerçek dışı yapmaz. JavaScript işe yarar.

“Ayrı bir API katmanı yok.” Tarayıcın doğrudan veritabanınla konuşuyor. Pek çok kişinin ilk içgüdüsü “bu doğru değil, arada bir API olmalı” olur. Ama API tam olarak “bu tablodan seç ve döndür” ya da “bu tabloya ekle” ise, aradaki katman hiçbir şey katmıyor demektir. Sadece ek yük oluyor. Veritabanın zaten bir API’dir. Yapabiliyorsan doğrudan çağır.

“Güvenlik konusunda endişeliyim.” Yapay zeka ile inşa edilen çoğu uygulama, makul varsayılanlarla gelir: şifreler hash’lenir, SQL enjeksiyonu mümkün değildir (veritabanı kütüphanesi bunu engeller), sırlar istemciden uzak tutulur. Gerçekten endişeliysen, yapman gereken şey builder’ına bu şeyleri yapıp yapmadığını sormak, refleks olarak bir backend eklemek değil. Kötü inşa edilmiş bir backend, iyi inşa edilmiş bir frontend’den daha savunmasızdır.

Dürüst Karar Ağacı

Tahmin yürütmeden bunu nasıl çözeceğin işte burada:

Uygulaman, şu anda yaptığı şeyi bir backend olmadan yapabiliyor mu? Evetse, 2’ye geç. Hayırsa, zaten bir backend’in var demektir (ya da bir tane inşa etmen gerekiyor). Devam et. (Yapay zeka ile inşa ettiğin uygulamanın zaten bir tanesi olabilir.)
Eklemek istediğin şey, tarayıcının temelde yapamayacağı bir şey mi? Para tahsil etmek? Kesinlikle. E-posta göndermek? Evet. Gizli bir anahtarla dış bir API çağırmak? Evet. Başka bir şey mi? Muhtemelen değil. Tarayıcının yapabileceği ama yavaş olan bir şeyse, 3’e geç. Tarayıcının yapamayacağı bir şeyse, bir backend’e ihtiyacın var.
Asıl sorunu düzeltirsen yavaşlık geçiyor mu? Daha az şey yükle? Daha akıllı önbellekle? İstekleri gruplandır? Daha iyi bir veritabanı kullan? İşin sırrı şu: önce gerçekte neyin yavaş olduğunu bul. Bir backend’i, ancak bariz düzeltmeleri tükettikten sonra ekle. Çünkü bir backend eklemek yavaş bir algoritmayı düzeltmez — sadece onu başka bir makineye taşır.
Bir backend eklersen, gerçekten sorunu çözüyor mu? Tuzak burada. “Performansı iyileştirmek” için bir backend eklersin, ve gecikme daha da kötüleşir çünkü artık backend’ine ağ çağrıları yapıyorsun, o da veritabanına ağ çağrıları yapıyor — halbuki bunu tarayıcıdan tek adımda yapabilirdin. Önce ölç. Sonra ekle.

Tam Bir Backend mi, Yoksa Sadece Bir Cloud Function mı Gerekiyor?

İstediğin şey, çağrıldığında birkaç saniye çalışıp duran tek bir fonksiyonun içine sığıyorsa, tam bir backend’e değil, bir cloud function’a ihtiyacın var demektir. İşte koku testi.

İstediğin şeyi backend’in ne yapmasını istediğini düşün. Şimdi bunu, çağrıldığında birkaç saniye çalışıp duran tek bir JavaScript fonksiyonu (belki 100 satır) olarak yazdığını hayal et. O kutuya sığdırabilir misin?

Ödeme webhook’larını işlemek? Evet.
Hoş geldin e-postası göndermek? Evet.
Yüklemeden önce bir dosyayı doğrulamak? Evet.
Gece boyu bir rapor çalıştırmak? Evet (bir bakıma — belirli bir zamanlamayla çağırırsın).

Cevap evetse, “gerçek bir backend”e ihtiyacın yok. Bir cloud function’a ihtiyacın var. Vercel, AWS Lambda, Google Cloud Functions, ne olursa olsun. Daha ucuz, daha basit, ve bir sunucuyu dadılık yapmana gerek yok.

Cevap hayırsa — sürekli çalışan, binlerce isteği işleyen, karmaşık iş mantığı olan bir şeye ihtiyacın varsa — o zaman gerçek bir backend düşünüyorsundur ve o konuşma daha önemlidir. Ama dürüst olmak gerekirse, bu, insanların yapay zeka ile inşa ettiği uygulamalar için nadirdir. “Backend işi” gibi görünen şeylerin çoğu, sadece “bu API’yi çağır” ya da “bu veriyi kaydet”tir, ki builder’ın bunu muhtemelen zaten ele alıyordur.

Builder’ına Sorman Gereken Gerçek Soru

Herhangi bir şey eklemeden önce, builder’ına tek bir soru sor: şu anda gerçekte ne bozuk ki bir backend bunu gerçekten düzeltir?

Somut bir cevapları varsa — “para tahsil etmemiz gerekiyor,” “gizli bir anahtarla bir API çağırmamız gerekiyor,” “veri çakışmamız var” — harika. Neye doğru inşa ettiğini biliyorsun demektir.

Cevap “eh, gerçek uygulamaların backend’i olur” ise, bu bir his, bir sebep değil. Hiç kimsenin paylaşmadığı bir uygulamaya kullanıcı hesapları eklemek istemene, ya da aslında üç şeyin olduğu yerde on beş tablolu bir veritabanı şeması eklemek istemene sebep olan hisle aynı his. Backend şapkası takan kapsam sürünmesinin kokusu.

Çoğu başarılı tek kişilik uygulamanın, senin hayal ettiğin anlamda “gerçek bir backend”i yoktur. Bir veritabanları vardır (builder’ın muhtemelen bunu zaten kurmuştur). Belirli bir zamanlamayla çalışan bir ya da iki fonksiyonları olabilir. Ama tarayıcıda çalışan kod işi yapar, doğrudan veritabanıyla konuşur, ve aradaki bir katman olmadan özellikleri yayına alır.

Uygulaman muhtemelen olduğu haliyle iyi. Öyle olmadığına dair his, genelde gerçeğin değil, hırsın sesidir. Bir backend’i, gerçek bir sorunu çözdüğünde ekle, öyle hissettiğin için değil.

Bir dahaki sefere bir özellik tasarlarken sor: Bu, tarayıcının temelde yapamayacağı bir şey mi? Yoksa kelimeyi yeterince duyduğun için mi bir backend’e ihtiyacı olduğunu düşünüyorsun? Bu iki sorunun cevabı farklıdır, ve bunlardan sadece biri senin işin.