Full-Stack Temelleri: Mobil Geliştirici İçin Backend Yolu

Mobil geliştirici olarak yıllarca yalnızca istemci tarafında kod yazdıysan, er ya da geç "backend öğrenmeli miyim?" sorusuyla karşılaşırsın. Bu rehber, mobil geliştirici için backend öğrenme yol haritasını HTTP'nin temellerinden CRUD API yazmaya, veritabanı modellemeden kimlik doğrulamaya, deploy ve izlemeden BaaS kısayoluna kadar adım adım anlatıyor. Amaç bir framework reklamı yapmak değil, hangi sırayla neyi öğrenmen gerektiğini netleştirmek.

💡 Pro Tip: İlk kararın "hangi dil" olmasın — önce HTTP'yi ve tek bir CRUD döngüsünü bir dilde bitir, dil değiştirmek sonradan kolaydır, sırayı atlamak pahalıdır.

İçindekiler

• Neden mobil geliştirici backend öğrenmeli
• Sıfırıncı adım: HTTP'yi gerçekten anlamak
• Method, status code ve header üçlüsü
• Aşama 1 — bir CRUD API yazmak (dil seçimi tuzağı)
• Neden Swift tarafında kalmak da mantıklı
• Aşama 2 — veritabanı ve veri modelleme
• Şema tasarımında dikkat edilecekler
• Aşama 3 — kimlik doğrulama ve oturum
• Kısa ömürlü token, uzun ömürlü refresh token
• Aşama 4 — deploy, log, izleme
• CI/CD ve modüler düşünme
• Log okumayı erken öğren
• BaaS kısayolu ne zaman doğru karar
• Öğrenme amacıyla BaaS kullanmanın bir bedeli var
• 90 günlük çalışma planı ve kaynaklar
• Planı bozmadan hızlandırmak
• SSS
• Mobil geliştirici backend'i nereden öğrenmeye başlamalı?
• iOS geliştiricisi için hangi backend dili mantıklı?
• Backend öğrenmek için hangi sırayla ilerlemeli?
• Kendi API'mi yazmalı mıyım yoksa BaaS mı kullanmalıyım?
• Backend öğrenmeyi bir hafta sonu projesine mi, aylara yayılan bir plana mı sığdırmalıyım?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Neden mobil geliştirici backend öğrenmeli

Mobil uygulaman büyük ihtimalle bir noktada bir sunucuyla konuşuyor: kullanıcı girişi, push bildirimi tetikleme, senkronizasyon, ödeme doğrulama — hepsi bir backend'e bağımlı. Bu bağımlılığı yalnızca "API'yi çağırıyorum" seviyesinde bilmek bir noktada seni tıkar: backend ekibiyle konuşurken neyin mümkün neyin mümkün olmadığını kestiremezsin, basit bir gecikme veya hata için haftalarca beklersin, kendi side-project'in için minik bir servis yazman gerektiğinde sıfırdan başlarsın.

Bunun tersi de doğru: backend'in temel mantığını (istemci-sunucu modeli, durum yönetimi, veri modelleme) anlayan bir mobil geliştirici, API tasarımı toplantılarında görüş bildirebilir, kendi prototiplerini uçtan uca kurabilir ve "bu neden bu kadar yavaş" sorusuna kendi başına cevap arayabilir. Bu rehberin geri kalanı, bu temeli en kısa yoldan nasıl kuracağını gösteriyor — kariyer vaadi değil, pratik bir yetkinlik haritası.

Bu, "artık full-stack geliştirici ol" çağrısı da değil. Amaç, mobil tarafındaki uzmanlığını bırakıp backend'e geçmen değil; ikisi arasındaki sınırı görebilecek kadar backend okuryazarlığı kazanman. Bu okuryazarlık üç somut yerde işine yarar: (1) hata ayıklarken sorunun istemcide mi sunucuda mı olduğunu daha hızlı ayırt edersin, (2) API sözleşmesi (contract) tartışmalarında hangi alanın neden gerekli olduğunu anlarsın, (3) küçük bir side-project veya prototip için kendi backend'ini kurman gerektiğinde sıfırdan araştırmaya başlamazsın. Bu üçü de "ne kadar sürede öğrenirim" sorusundan önce gelen, daha temel bir motivasyon.

Sıfırıncı adım: HTTP'yi gerçekten anlamak

Mobil uygulaman ile backend'in arasındaki her konuşma HTTP üzerinden yürür; bu yüzden backend öğrenmenin gerçek sıfırıncı adımı bir framework değil, protokolün kendisidir. MDN'in tanımıyla HTTP, istemcinin bağlantı açıp istek gönderdiği, sunucunun cevap verene kadar beklediği klasik bir istemci-sunucu protokolüdür. Bunun kritik sonucu: HTTP durumsuzdur (stateless) — sunucu iki istek arasında oturum verisini kendiliğinden tutmaz; "kullanıcı giriş yaptı" bilgisini her istekte yeniden taşımak (token, cookie) senin sorumluluğundur.

Method, status code ve header üçlüsü

• Request method: isteğin amacını ve başarılı olursa ne beklendiğini belirtir (GET okuma, POST oluşturma, vb.).
• Status code: cevaplar beş sınıfa ayrılır — bilgilendirme, başarı, yönlendirme, istemci hatası, sunucu hatası; mobil tarafta 4xx/5xx ayrımını doğru yapmak retry mantığını doğrudan etkiler.
• Header: kaynak veya mesaj hakkında metadata taşır (içerik tipi, cache kuralları, auth token'ı).

Bu üç kavramı net kurmadan yazdığın bir network katmanı her zaman kırılgan kalır — retry, timeout ve cache kararları hep bu temele dayanır.

Aşama 1 — bir CRUD API yazmak (dil seçimi tuzağı)

Buradaki en yaygın tuzak "hangi backend dili en iyisi" sorusuna takılıp kalmaktır. roadmap.sh'nin backend yol haritası bu soruyu bilerek ikinci plana atar: önce Python, Ruby, Java, Go gibi bir dil seç, sonra o dilin paket yöneticisini ve dış paket kurmayı öğren. roadmap.sh'nin kendi sıralamasında bundan sonra ilişkisel veritabanı gelir, RESTful API ile authentication/authorization ise aynı adımda birlikte öğrenilir; bu rehber pedagojik nedenlerle CRUD API'yi veritabanından önce ele alıyor. Dil seçimi üzerine kurduğun beceriyi taşıyabileceğin bir detaydır; CRUD döngüsünü (create/read/update/delete) bir kez kavradığında ikinci dile geçmek çok daha hızlıdır.

1// Basit CRUD akışı (dilden bağımsız pseudocode)
2POST   /notes        -> yeni not oluştur (Create)
3GET    /notes/:id    -> tek notu getir (Read)
4GET    /notes        -> tüm notları listele (Read)
5PUT    /notes/:id    -> notu güncelle (Update)
6DELETE /notes/:id    -> notu sil (Delete)
7 
8// Her uç nokta HTTP status code sınıfına göre cevap döner:
9// 201 Created, 200 OK, 404 Not Found, 400 Bad Request

Neden Swift tarafında kalmak da mantıklı

iOS tarafından geliyorsan, backend'i de Swift'te denemek geçiş maliyetini düşürür: server-side Swift ekosistemi ve özellikle Vapor ile backend API yazımı sana aynı dilde CRUD, routing ve middleware kavramlarını öğretir. Dil aynı kalınca öğrenme yükün yalnızca "backend kavramları" olur, syntax değil — ama roadmap.sh dili açık uçlu listelediği için (Python, Ruby, Java, Go vb.) bu bir zorunluluk değil, geçiş maliyetini düşüren bir tercihtir.

Aşama 2 — veritabanı ve veri modelleme

CRUD API bir noktada kalıcı veriye ihtiyaç duyar; roadmap.sh'nin kendi sıralamasında bu adım aslında dil ve paket yöneticisinden hemen sonra, RESTful API'den önce gelir. roadmap.sh burada net bir öneri veriyor: ilişkisel bir veritabanının (örnek olarak PostgreSQL) temellerini öğren ve üzerinde basit CRUD operasyonları çalıştırmayı öğren. Mobil tarafta zaten CloudKit veya Core Data ile senkronizasyon deneyimin varsa bu kavramlar sana yabancı gelmeyecek — CloudKit senkronizasyonu yazısındaki çakışma çözümü ve şema düşünme biçimi, sunucu tarafı bir ilişkisel şemayı modellerken de işine yarar.

1CREATE TABLE notes (
2  id SERIAL PRIMARY KEY,
3  user_id INTEGER NOT NULL REFERENCES users(id),
4  title TEXT NOT NULL,
5  body TEXT,
6  created_at TIMESTAMP DEFAULT now()
7);
8 
9-- roadmap.sh'nin önerdiği "ilişkisel DB + basit CRUD" adımının
10-- karşılığı: user_id ile bire-çok ilişki, birincil anahtar id.

Şema tasarımında dikkat edilecekler

• Birincil anahtar: her tabloda benzersiz kimliği garanti eder.
• İlişkiler: bire-çok, çoka-çok — mobil tarafta gördüğün nesne grafiğinin sunucu karşılığıdır.
• Migration disiplini: erken kurulmazsa şema değişiklikleri prod'da acı verir.

Buradaki en büyük zihniyet değişimi, veriyi "nesne grafiği" olarak değil "ilişkisel tablo" olarak düşünmeyi öğrenmek. Mobil tarafta bir Note nesnesinin bir User'a ait olduğunu bir referans/pointer ile ifade edersin; ilişkisel modelde bu, notes tablosundaki user_id sütununun users tablosuna bir yabancı anahtar (foreign key) ile bağlanmasıyla ifade edilir. roadmap.sh'nin vurguladığı "basit CRUD operasyonları" da tam olarak bu: bir satırı oluşturmak, o satırı ilişkili anahtarıyla birlikte okumak, güncellemek ve silmek. Migration'ları en başından bir araçla (herhangi bir dilin kendi migration kütüphanesi) takip etmeye başlamak, şemanı elle SQL yazarak değiştirmekten çok daha az riskli bir alışkanlıktır.

Aşama 3 — kimlik doğrulama ve oturum

roadmap.sh auth'u ayrı bir aşama olarak değil, RESTful API adımının içinde konumlandırır: "build a simple RESTful API and implement simple Authentication/Authorization into it". Bu rehber öğrenme kolaylığı için onu ayrı bir aşama olarak ele alıyor. Mobil tarafta zaten "kullanıcı girişi" akışını UI olarak defalarca kurdun; burada öğrenmen gereken, o girişin sunucu tarafında nasıl doğrulandığı ve oturumun (token, refresh token) nasıl taşındığıdır.

1# Basit bir Authorization header örneği (token tabanlı oturum)
2curl -X GET https://api.ornek-servis.dev/notes \
3  -H "Authorization: Bearer <token>"
4 
5# Sunucu tarafında token doğrulanır; 401 dönerse istemci
6# (mobil uygulama) kullanıcıyı yeniden login akışına yönlendirir.

Güvenlik tarafında mobil geliştiricinin zaten bildiği prensipler — hassas veriyi cihazda güvenli saklama, token'ı düz metin loglamama — burada da geçerlidir; iOS güvenlik pratiklerini anlatan yazı, istemci tarafında token'ı nasıl saklaman gerektiğine dair aynı disiplini taşıyor.

Kısa ömürlü token, uzun ömürlü refresh token

Backend tarafında öğrenmen gereken bir diğer temel kalıp, tek bir token yerine iki token kullanmaktır: kısa ömürlü bir erişim token'ı (access token) her isteğe eklenir ve çalınsa bile hızla geçersiz kalır; uzun ömürlü bir yenileme token'ı (refresh token) ise yalnızca erişim token'ını yenilemek için, daha az sıklıkla kullanılır. Sunucu tarafında bunu doğrulamak, HTTP'nin durumsuz doğasına (yukarıdaki sıfırıncı adım) tam olarak uyar: sunucu senin kim olduğunu hatırlamaz, sen her istekte kanıtını (token) yeniden sunarsın.

Aşama 4 — deploy, log, izleme

Kod çalışır hale geldikten sonra asıl sınav başlar: onu güvenilir şekilde ayakta tutmak. 12-Factor App metodolojisi (Adam Wiggins), production-ready backend'in temel ilkelerini net biçimde tarif eder ve bu ilkeler dil/framework'ten bağımsızdır.

CI/CD ve modüler düşünme

Bu ilkeleri elle takip etmek yerine bir pipeline'a devretmek, mobil tarafta zaten alışık olduğun bir alışkanlık: iOS CI/CD pipeline kurarken öğrendiğin "build, test, deploy aşamalarını ayır" mantığı birebir 12-Factor'ün build/run ayrımına karşılık gelir. Aynı şekilde backend'i tek bir dev dosyası yerine sorumluluklara göre bölmek, modüler mimari yazısındaki modül sınırı düşüncesiyle aynı disiplini paylaşır.

Log okumayı erken öğren

12-Factor'ün "logları event stream olarak ele al" ilkesi ilk bakışta soyut görünür, ama pratikte tek bir şey demek istiyor: sunucunun ne yaptığını dosya sistemine kendi elinle yazıp yönetmeye çalışma, standart çıktıya (stdout) yaz ve bu akışı okuyacak bir araca bırak. Mobil tarafta bir crash log'unu nasıl okuyup bir hatayı tersine mühendislik yaptıysan, backend tarafında da bir hatayı ilk önce log satırlarında ararsın — bu yüzden en basit "merhaba dünya" API'nde bile her isteğin ne zaman geldiğini ve nasıl sonuçlandığını (status code'uyla birlikte) loglamayı en baştan alışkanlık haline getir.

BaaS kısayolu ne zaman doğru karar

Her backend'i sıfırdan yazmak zorunda değilsin. 12-Factor'ün "backing service'leri bağlı kaynak olarak ele al" ilkesi burada yol gösterir: kimlik doğrulama, veritabanı veya dosya depolamayı yönetilen bir servise (BaaS) devretmek, o servisi de bağlı bir kaynak olarak gördüğün sürece mimarini kirletmez. Firebase'in ileri seviye kalıplarını anlatan yazı, bu tarz yönetilen servislerin auth ve veri katmanını nasıl soyutlayabileceğine iyi bir örnek.

Karar basit bir soruya indirgenebilir: ekibin/projenin zaman kısıtı mı öncelikli, yoksa backend mantığının tamamına kendi kontrolün mü gerekiyor? Cevap net değilse, önce yönetilen bir servisle başlayıp CRUD/auth temel katmanını kendi elinle bir kez kurduktan sonra karar vermek, hiç denemeden karar vermekten daha sağlıklıdır.

Öğrenme amacıyla BaaS kullanmanın bir bedeli var

Burada bir uyarı da eklemek gerekiyor: bu rehberin amacı CRUD/DB/auth kavramlarını senin kendi ellerinle bir kez kurmandır. Bu öğrenme aşamasını tamamen bir BaaS'a devredersen (örneğin auth'u tamamen yönetilen bir servise bırakırsan), o servisin arkasında ne olduğunu anlamadan ilerlemiş olursun — ki bu tam olarak bu rehberin çözmeye çalıştığı problemdir. Bu yüzden en azından bir kez, küçük bir projede, auth'u ve veritabanını kendi elinle kurman öneriliyor; BaaS'a geçiş kararını bu deneyimden sonra, bilinçli olarak vermelisin.

90 günlük çalışma planı ve kaynaklar

Bu rehberin kendi sıralaması (dil → CRUD API → veritabanı → auth → deploy) aşağıda zaman dilimlerine bölünüyor; roadmap.sh'nin kendi sırası veritabanını RESTful API'den önce, authentication/authorization'ı ise RESTful API ile aynı adımda önerir — burada pedagojik nedenlerle farklı bir sıra izleniyor, bitirme garantisi veya iş bulma vaadi olmadan, yalnızca bir uygulama sırası olarak:

• 1-15. gün: Bir dil seç, paket yöneticisini öğren, "merhaba dünya" API'sini ayağa kaldır.
• 16-35. gün: Tek bir kaynak (ör. "not") için CRUD uç noktalarını yaz; test-driven yaklaşımı mobil tarafta öğrendiğin gibi burada da testi önce yazmayı dene.
• 36-55. gün: İlişkisel veritabanını bağla, şemayı modelle, migration akışını kur.
• 56-70. gün: Basit auth/oturum ekle; token'ı mobil istemciden nasıl taşıyacağını netleştir.
• 71-85. gün: 12-Factor ilkelerine göre deploy et, logları merkezi bir yere ak.
• 86-90. gün: Var olan mobil projenle gerçek bir uçtan uca entegrasyon dene.

roadmap.sh ayrıca sürekli proje üretmenin öğrenmenin ayrılmaz bir parçası olduğunu vurguluyor — bu planı bir kez bitirmek değil, her 90 günde farklı bir kaynak/ilişki modeliyle tekrar etmek asıl kazanımı getirir.

Planı bozmadan hızlandırmak

Bu 90 günlük çerçeve bir taahhüt değil, bir iskelet. Zamanın kısıtlıysa gün sayılarını yarıya indirebilirsin, ama sırayı değiştirme: veritabanını auth'tan önce, auth'u deploy'dan önce öğrenmek, her aşamanın bir öncekinin üzerine gerçekten oturmasını sağlar. roadmap.sh'nin Git/GitHub'ı ayrı bir madde olarak vurgulaması da tesadüf değil — sürüm kontrolü olmadan bu altı aşamayı geriye dönüp karşılaştıramazsın; her aşamanın sonunda küçük bir commit atmak, hangi kavramı hangi haftada öğrendiğini kendi geçmişinde görünür kılar.

SSS

Mobil geliştirici backend'i nereden öğrenmeye başlamalı?

Bir framework seçerek değil, önce HTTP protokolünün istemci-sunucu ilişkisini ve durumsuz doğasını kavrayarak başla; roadmap.sh'nin önerdiği sırayla ilerlemek (dil → paket yöneticisi → veritabanı → REST API + auth) seni framework detaylarında kaybolmaktan korur.

iOS geliştiricisi için hangi backend dili mantıklı?

Zaten Swift biliyorsan server-side Swift (ör. Vapor) geçiş maliyetini düşürür çünkü syntax'ı tekrar öğrenmene gerek kalmaz; ama roadmap.sh dil seçimini ikincil bir karar olarak ele alır — Python, Go veya Java ile de aynı kavramları öğrenebilirsin.

Backend öğrenmek için hangi sırayla ilerlemeli?

roadmap.sh'nin sıralaması: önce bir dil ve paket yöneticisi, sonra ilişkisel veritabanı ve CRUD operasyonları, ardından basit bir RESTful API ile birlikte authentication/authorization — bu sıra atlanınca öğrenilen kavramlar birbirine bağlanmaz.

Kendi API'mi yazmalı mıyım yoksa BaaS mı kullanmalıyım?

12-Factor App'in "backing service'leri bağlı kaynak olarak ele al" ilkesine göre düşünürsen ikisi de geçerli seçenektir; zaman kısıtın öncelikliyse yönetilen bir servisle başlayıp CRUD/auth temelini bir kez kendi elinle kurduktan sonra karar vermek daha sağlıklıdır.

Backend öğrenmeyi bir hafta sonu projesine mi, aylara yayılan bir plana mı sığdırmalıyım?

roadmap.sh'nin kendisi bir bitiş tarihi vermiyor, bu yüzden burada da bir süre vaadi yok; yukarıdaki 90 günlük çerçeve bir iskelet, taahhüt değil. Önemli olan süre değil sıra: dil → HTTP/REST → veritabanı → auth → deploy sırasını bozmadan ilerlediğin sürece, bunu bir hafta sonu projesine de altı aya da yayabilirsin.

Güncelleme (Eylül 2026)

Bu yazı ilk kez 30 Ekim 2024'te, o tarihteki araç ve sürümlere göre yazıldı. Aradan geçen sürede yol haritasının sırası (dil → HTTP/REST → veritabanı → auth → deploy) kavramsal olarak değişmedi, ama birkaç noktada güncel bilgi eklemek gerekiyor.

Kimlik doğrulama tarafında IETF, Ocak 2025'te RFC 9700'ü ("Best Current Practice for OAuth 2.0 Security") yayınladı ve implicit grant akışını artık önermiyor; authorization code + PKCE kombinasyonu tavsiye edilen yöntem. 2024'te FIDO Alliance adına yapılan bağımsız ankete göre kullanıcıların %53'ü en az bir hesapta passkey aktifleştirmiş durumda — yani auth bölümünü öğrenirken artık yalnızca parola+token değil, passkey/WebAuthn'ı da göz önünde bulundurmak gerekiyor.

Veritabanı tarafında PostgreSQL 18, Eylül 2025'te yayınlandı ve PostgreSQL 19 Eylül 2026 itibarıyla beta aşamasında; Node.js tarafında Node 24 Active LTS'te (EOL 30 Nisan 2028), Node 22 ise 21 Ekim 2025'ten beri Maintenance LTS'te (EOL 30 Nisan 2027). roadmap.sh'nin "ilişkisel DB öğren" tavsiyesi hâlâ geçerli, yalnızca hangi sürümle çalıştığını netleştirmek gerekiyor.

Runtime seçiminde de değişen bir şey var: Bun, yerleşik Postgres ve S3 istemcileriyle (Redis istemcisi sonraki 1.2.x sürümlerinde eklendi) Node.js'e gerçek bir alternatif haline geldi.

BaaS tarafında Supabase bugün SOC 2 Type 2, HIPAA ve ISO 27001 sertifikalarına sahip — "kendi API'ni mi yaz, BaaS mı kullan" kararında yönetilen servis tarafı artık prototipten üretime daha güvenle taşınabilir bir seçenek. 12-Factor App metodolojisinde ve OWASP API Security Top 10 listesinde ise doğrulanabilir bir değişiklik yok; her ikisi de yazıldığı haliyle geçerliliğini koruyor.

Sonuç

Mobil geliştirici olarak backend öğrenmek bir dil seçmekle başlamaz; HTTP'nin durumsuz doğasını kavramakla başlar. Oradan CRUD API'ye, veritabanına, auth'a ve deploy disiplinine adım adım ilerlersin — her aşamada mobil tarafta zaten bildiğin bir kavramın sunucu tarafındaki karşılığını bulursun. Network katmanı optimizasyonu yazısı bu HTTP temelinin mobil tarafta nasıl kullanıldığını, CloudKit senkronizasyonu veri modelleme sezgini, iOS güvenlik pratikleri auth disiplinini, iOS CI/CD pipeline deploy alışkanlığını, modüler mimari ise backend'i bölme mantığını tamamlıyor. Sıradan sapmadan ilerlersen, hangi dili seçersen seç aynı temel üzerine inşa edersin.

Kaynaklar

• MDN Web/HTTP genel bakış — istemci-sunucu modeli, durumsuzluk, status code sınıfları ve header'ların tanımı.
• 12factor.net — config, backing services, build/release/run, stateless process, port binding, logs, admin process ve disposability ilkeleri.
• roadmap.sh/backend — dil seçimi, paket yöneticisi, ilişkisel veritabanı + CRUD, ardından RESTful API ve auth sıralı öğrenme yolu.
• RFC 9700 — Best Current Practice for OAuth 2.0 Security — implicit grant yerine authorization code + PKCE tavsiyesi (Ocak 2025).
• PostgreSQL Versioning Policy — PostgreSQL 18/19 sürüm takvimi.
• FIDO Alliance — Passkeys — passkey/WebAuthn benimseme oranları.
• Node.js Release Schedule — Node 24 Active LTS ve Node 22 Maintenance LTS destek takvimi.
• Bun v1.2 duyurusu — yerleşik Postgres ve S3 istemcileri.
• Bun v1.2.9 duyurusu — yerleşik Redis/Valkey istemcisi.
• Supabase Security — SOC 2 Type 2, HIPAA ve ISO 27001 sertifikasyonları.
• OWASP API Security Top 10 — güncel edisyon listesi.