Drupal ile Mobil Uygulama: API-First Yaklaşımı

Bir kurum mobil uygulama geliştirmeye karar verdiğinde ilk soru genellikle uygulamanın kendisiyle ilgili değildir. Asıl soru, içeriğin nereden geleceğidir. Ders kataloğu, duyurular, akademisyen profilleri, etkinlik listeleri, haberler; bütün bu içerik zaten bir içerik yönetim sisteminde bulunur ve uygulamanın bu içeriğe güvenilir bir yoldan erişmesi gerekir. Drupal'a API-first yaklaşımının devreye girdiği yer tam da burasıdır. Mobil uygulamayı kendi içerik deposu olan ayrı bir proje olarak görmek yerine, Drupal'ı web sitesini, uygulamayı ve gelecekteki her kanalı tek ve tutarlı bir API setinden besleyen ortak backend hâline getirirsiniz.

Bu yazıda Drupal üzerinde API-first mimariyle nasıl mobil uygulama geliştirileceğini ele alıyoruz. "API-first" ile "headless" arasındaki farkı netleştiriyor, bu modelin mobil için neden bu kadar uygun olduğunu inceliyor, API ve kimlik doğrulama katmanlarını adım adım açıklıyor, çoğu rehberin atladığı mobil-özel konulara giriyor ve ne kadar decouple edileceğine dair net bir karar çerçevesi sunuyoruz.

API-First ve Headless: Kavram Karışıklığını Gidermek

Bu iki terim çoğu zaman birbirinin yerine kullanılır; ancak farklı şeyleri anlatırlar ve bu ayrımı anlamak, projeyi nasıl planlayacağınızı doğrudan etkiler.

Headless bir mimariyi tanımlar: Kullanıcının gördüğü ön yüz, içeriğin durduğu arka yüzden ayrılır ve ikisi bir API üzerinden haberleşir. Headless kurulumda Drupal sayfaları kendisi oluşturmayı bırakır ve ham içeriği ayrı bir ön yüz uygulamasına devreder.

API-first ise bir tasarım felsefesini tanımlar: İçerik en baştan API olarak modellenir ve sunulur; böylece aynı anda çok sayıda kanalı besleyebilecek hâle gelir. Bir web sitesi, bir iOS uygulaması, bir Android uygulaması, bir akıllı saat, bir kiosk ya da bir sesli asistan. Headless tek bir ön yüzü ayırmakla ilgilidir; API-first ise bunların hepsine baştan hazır olmakla ilgilidir. Mobil uygulama çoğu zaman API-first'e geçişin tetikleyicisidir; ancak asıl kazanç, aynı backend'in kurumun ileride ekleyeceği her kanalı, içerik katmanını her seferinde yeniden kurmadan besleyebilmesidir.

Drupal ikisi için de uygundur; çünkü API yetenekleri sonradan eklenen bir katman değil, çekirdeğin parçasıdır. Drupal 8'den bu yana gelen ve Drupal 9, 10 ve 11 ile olgunlaşan web servisleri katmanı, yapılandırılmış içeriği hiç özel kod yazmadan API yanıtlarına dönüştürür. Bu yazıdaki her şeyin üzerine kurulduğu temel budur.

Mobil Uygulama İçin API-First Neden Doğru Temeldir?

Bir mobil uygulama için API-first Drupal backend'i seçmek, yalnızca lansmanda değil, projenin tüm ömrü boyunca kendini gösteren avantajlar sağlar.

• Tek içerik kaynağı, çok kanal: Aynı duyuru, ders ya da profil Drupal'a bir kez girilir ve web sitesine, mobil uygulamaya ve varsa diğer kanallara aynı anda ulaştırılır. Editörler içeriği iki kez düzenlemez ve uygulama, siteyle asla uyumsuz hâle gelmez.
• Yapılandırılmış içerik, her arayüze hazır: Drupal içeriği hazır sayfalar olarak değil yapılandırılmış veri olarak sakladığı için, bu içerik mobil arayüze temiz biçimde oturur. Bir ders, tek parça HTML değildir; uygulamanın istediği gibi düzenleyebileceği alanlardan (başlık, kredi, öğretim üyesi, program) oluşur.
• Ön yüz ve arka yüz birbirinden bağımsız gelişir: API sözleşmesi korunduğu sürece uygulama ekibi backend'e dokunmadan yeni sürüm çıkarabilir, içerik ekibi de uygulamayı bozmadan backend'i yeniden yapılandırabilir. Bir taraftaki güncelleme diğer tarafı yeniden kurmaya zorlamaz.
• Geleceğe hazır bir yatırım: Yeni bir kanal ortaya çıktığında (yeni bir uygulama, bir kampüs ekran sistemi ya da başka bir platformla entegrasyon) içerik zaten sunulmuş ve hazır bekliyordur. Kurum yeni bir backend değil, yalnızca yeni bir ön yüz kurar.
• Uygulamanın ardında kurumsal düzeyde içerik yönetimi: Uygulama, Drupal'ın editöryal iş akışlarını, ayrıntılı yetkilendirmesini, çok dilli desteğini ve medya yönetimini devralır. Bunlar, sıfırdan yazılan bir mobil backend'in yeniden icat etmesi gereken yeteneklerdir.

API Katmanı: JSON:API, REST ve GraphQL

Drupal içeriği üç temel spesifikasyonla sunabilir. Bunlar birbirinin rakibi olmaktan çok farklı araçlardır ve doğru seçim uygulamanın ihtiyacına göre değişir.

Çoğu mobil proje için doğal başlangıç noktası JSON:API'dir. Çekirdeğin parçasıdır, açmak için yapılandırma gerektirmez ve katı bir spesifikasyonu izler; bu da mobil geliştiricinin yanıtların tam olarak nasıl görüneceğini bilmesi anlamına gelir. Yapısı ayrıca içerikler arasındaki ilişkileri (bir ders ile öğretim üyesi, bir etkinlik ile mekânı) öngörülebilir biçimde ele alır ki bu, kurumsal uygulamalarda sık karşılaşılan bir ihtiyaçtır. GraphQL ise bir uygulama ekranının aynı anda pek çok farklı veri parçasını çekmesi ve birden fazla gidiş-dönüşten kaçınmak istemeniz durumunda cazip hâle gelir; karşılığında ek kurulum ve karmaşıklık getirir. Genel kural şudur: JSON:API ile başlayın, yalnızca somut bir performans ihtiyacı gerektirdiğinde GraphQL'e geçin.

Kimlik Doğrulama: Mobil Uygulamalar Neden Çereze Güvenemez?

Kimlik doğrulama, decoupled bir mobil projedeki ilk gerçek teknik engeldir ve pek çok ekibi hazırlıksız yakalar. Geleneksel bir Drupal sitesi kullanıcıları, tarayıcının yönettiği oturum çerezleriyle doğrular. Native bir mobil uygulamanın ise tarayıcısı ve çerez saklama alanı yoktur; dolayısıyla bu mekanizma orada işlemez. Uygulamanın kimliği farklı bir yolla doğrulaması gerekir.

Standart çözüm, token tabanlı kimlik doğrulamadır. Kullanıcı bilgilerini bir kez girer, uygulama bunları Drupal'a gönderir, Drupal doğrulayıp bir token döndürür ve uygulama bu token'ı saklayıp sonraki her isteğe ekler. İki yaklaşım öne çıkar:

• OAuth 2.0 (Simple OAuth modülü): Çoğu decoupled uygulama için önerilen yaklaşımdır. Erişim ve yenileme token'ları üretir, mobil uygulamalar gibi public istemciler için PKCE dahil modern akışları destekler ve merkezi kimlik sistemleriyle temiz biçimde entegre olur. Kurumsal projelerin çoğu bu yolu izler.
• JWT (JSON Web Token): Token'ın kullanıcının kimliğini kendi içinde taşıdığı hafif bir alternatiftir. Basit ve durum tutmayan yapısıyla, karmaşık yetkilendirme ihtiyacı olmayan uygulamalar için uygundur.

Zaten tek oturum açma (SSO) kullanan kurumlarda OAuth katmanı, uygulamayı her yerde kullanılan aynı merkezi kimlik sağlayıcısına bağlayabilir; böylece öğrenciler ve personel uygulamaya zaten sahip oldukları bilgilerle giriş yapar. Kimlik doğrulamayı en baştan doğru kurmak önemlidir; çünkü güvenli bir token akışını, daha basit bir varsayım üzerine kurulmuş bir uygulamaya sonradan eklemek, en baştan tasarlamaktan çok daha zordur.

Mobil-Özel Katman: Çevrimdışı, Bildirim ve Medya

Decoupled Drupal üzerine yazılan çoğu rehber API ve kimlik doğrulamada durur. Oysa mobil uygulama; bağlantısı kesintili, bant genişliği sınırlı ve kendi bildirim sistemi olan bir cihazda çalışır. Bu gerçekler, bir web sitesinin asla gerektirmediği bir planlama ister.

• Çevrimdışı erişim ve önbellekleme: Mobil kullanıcı, uygulamanın metroda ya da sinyalin zayıf olduğu bir amfide çalışmasını bekler. Uygulama içeriği yerel olarak önbelleğe almalı ve bağlantı geri geldiğinde Drupal ile senkronlanmalıdır. API katmanı, uygulamanın saklayıp yenileyebileceği önbelleklenebilir ve yapılandırılmış yanıtlar sunarak bunu destekler; ancak önbellek ve senkron mantığı uygulama tarafında yer alır ve bilinçli biçimde tasarlanmalıdır.
• Push bildirimleri: Bildirimler, kurumların native uygulama istemesinin başlıca sebeplerinden biridir. Yeni bir not, program değişikliği ya da acil bir uyarı gibi. Burada Drupal tetikleyici kaynak olarak çalışır: İçerik yayınlandığında ya da bir olay tetiklendiğinde Drupal, bildirimi cihazlara ileten bir push servisine (örneğin Firebase Cloud Messaging) çağrı yapar. İçerik ve tetikleyici Drupal'da yaşar; iletim ise platformun bildirim altyapısı tarafından üstlenilir.
• Medya ve görsel optimizasyonu: Mobil ekranlar ve mobil veri paketleri, görsel yönetimini kritik hâle getirir. Drupal'ın medya sistemi ve görsel biçimleri (image styles), her görselin uygun boyutlu sürümlerini üretebilir; böylece uygulama, masaüstü için hazırlanmış tam çözünürlüklü bir dosyayı indirmek yerine mobil için optimize edilmiş bir sürüm ister. Bu, yüklenme sürelerini ve veri kullanımını doğrudan etkiler.
• Orta yol olarak Progressive Web App: Her kurumun tam kapsamlı bir native uygulamaya ihtiyacı yoktur. Progressive Web App (PWA), native deneyimin büyük kısmını (ana ekrana kurulum, çevrimdışı destek, push bildirimleri) tek bir web kod tabanından sunar ve Drupal bunu özel bir PWA modülüyle destekler. Pek çok kampüs için PWA, native geliştirmeye geçmeden önce uygulama benzeri bir deneyime ulaşmanın daha düşük maliyetli bir yoludur.

Decoupled mı, Progressively Decoupled mı, Coupled mı?

Tamamen decoupled bir mimariye geçmek gerçek bir taahhüttür ve her zaman doğru cevap değildir. Ne zaman decouple edilmemesi gerektiği konusunda dürüst olmak, ne zaman edileceğini bilmek kadar önemlidir. Üç temel model vardır:

• Coupled (geleneksel Drupal): Drupal hem içeriği hem sunumu yönetir. Ayrı bir uygulaması ya da ön yüz çerçevesi olmayan standart bir web sitesi için doğru seçim budur. Ortada mobil uygulama ve ikinci bir kanal yoksa, decouple etmek fayda sağlamadan maliyet ekler.
• Progressively decoupled (kademeli): Drupal sayfanın büyük kısmını kendisi oluşturur, ancak belirli etkileşimli bileşenleri bir JavaScript çerçevesine devreder. Bu, Drupal'ın editöryal ve düzen araçlarını korurken ihtiyaç duyulan yerlere zengin etkileşim ekler. Uygulama benzeri davranış isteyen ama tam bir yeniden kurulum istemeyen bir site için işe yarayan bir orta yoldur.
• Fully decoupled (tam ayrık): Drupal yalnızca bir backend olur ve bir ya da daha fazla bağımsız ön yüz (bir mobil uygulama, ayrı bir web uygulaması) onun API'lerini kullanır. Native mobil uygulamanın gerektirdiği model budur ve gerçekten birden fazla kanala hizmet ettiğinizde doğru seçimdir. Ancak bu, yönlendirmeden SEO'ya ve erişilebilirliğe kadar Drupal'ın eskiden üstlendiği sorumlulukların ön yüz ekibine geçmesi anlamına gelir.

Belirleyici etken, içeriğin kaç ön yüze hizmet etmesi gerektiğidir. Tek bir web sitesi en iyi coupled hâlde tutulur. Bir web sitesi artı native bir mobil uygulama ise decoupled ya da hibrit bir mimariye işaret eder. Asıl hata, decouple etmeyi kendi başına bir amaç hâline getirmektir. Yalnızca tek bir web sitesine ihtiyaç duyan bir proje için tam decoupled bir kurulum, kurumun yıllarca bakımını üstleneceği bir karmaşıklık ve maliyet ekler. Platformlar arasındaki daha geniş dengeleri Drupal, WordPress ve Joomla karşılaştırmamızda ele almıştık.

Ön Yüz Tercihleri: React Native, Flutter ve Native

API-first bir Drupal backend'i ön yüzden bağımsız olduğu için, ekibin tercih ettiği hangi mobil teknolojiyse onunla çalışır. API, kendisini neyin tükettiğiyle ilgilenmez; bu da kararın uygulamanın gereksinimlerine ve ekibin becerilerine göre verilmesini sağlar.

• React Native: Tek bir JavaScript kod tabanından iOS ve Android uygulaması üreten, yaygın kullanılan çapraz platform seçeneğidir. Drupal'ın JSON:API'siyle doğal biçimde uyum sağlar; arkasında geniş bir ekosistem ve geliştirici havuzu vardır.
• Flutter: Google'ın Dart dilini kullanan çapraz platform çerçevesidir; akıcı performansı ve platformlar arası tutarlı görünümüyle bilinir. Drupal'ın API'lerini diğer istemciler kadar kolay tüketir.
• Native (Swift / Kotlin): iOS (Swift) ve Android (Kotlin) için ayrı ayrı geliştirmek, en derin platform entegrasyonunu ve en iyi performansı sağlar; karşılığında geliştirme maliyeti daha yüksektir. Drupal backend'i hepsine aynı şekilde hizmet eder.

Buradaki temel nokta, bunun gerçekten açık bir tercih olmasıdır. Backend standart API'ler sunduğu için kurum tek bir ön yüz teknolojisine bağlı kalmaz ve ileride içerik katmanına dokunmadan bu tercihi değiştirebilir.

API-First Mobil Projelerde Sık Yapılan Hatalar

• Gerek yokken decouple etmek: En sık yapılan hatadır. İkinci bir kanal yoksa coupled bir Drupal sitesi daha basit, daha ucuz ve bakımı daha kolaydır. Mobil uygulamanız olduğu için decouple edin, modern göründüğü için değil.
• Kimlik doğrulamayı sona bırakmak: Token tabanlı kimlik doğrulama, uygulamanın tüm mimarisini şekillendirir. OAuth ya da JWT akışını, uygulama oturum varsayımları üzerine kurulduktan sonra değil, en baştan tasarlayın.
• Ön yüzün artık neyi üstlendiğini unutmak: Decoupled bir kurulumda ön yüz ekibi; yönlendirme, SEO, erişilebilirlik ve metadata gibi Drupal'ın eskiden otomatik yaptığı işleri devralır. Bunların açıkça planlanması gerekir, yoksa hiç yapılmaz.
• Mobil-özel katmanı görmezden gelmek: Çevrimdışı davranış, bildirimler ve görsel optimizasyonu sonradan düşünülecek şeyler değildir. Zayıf bağlantıyı yönetmeyen ya da masaüstü boyutunda görseller sunan bir uygulama, API ne kadar temiz olursa olsun bozuk hissettirir.
• Gereğinden fazla veri çekmek: Bir ekranın ihtiyacından fazlasını istemek bant genişliği ve pil tüketir. Yalnızca gerekeni çekmek için JSON:API'nin alan filtrelemesini ya da uygun olduğunda GraphQL'i kullanın.
• API'yi sonradan düşünülen bir şey gibi ele almak: API-first'ün bütün amacı, içerik modelini ve API'sini en baştan bilinçli tasarlamaktır. Dışarıdan tüketilmesi hiç düşünülmemiş bir içerik yapısına sonradan API eklemek, hantal ve verimsiz uç noktalara yol açar.

Özenle yapıldığında API-first bir Drupal backend'i, kuruma web sitesini, mobil uygulamayı ve sonrasında geleni besleyebilecek tek ve iyi yapılandırılmış bir içerik kaynağı verir; hem de içeriği çoğaltmadan ya da temeli her seferinde yeniden kurmadan. Bu yaklaşım, zaten Drupal'ın yapılandırılmış içeriğine güvenen ve onu yeni kanallara taşımak isteyen kurumlar için doğal bir seçimdir. Nitekim Drupart bünyesinde Drupal4edu ekibinin Sabancı Üniversitesi, Yıldız Teknik Üniversitesi ve Işık Üniversitesi gibi kurumlar için geliştirdiği Drupal platformları, tam da bu tür çok kanallı senaryolara zemin hazırlayan yapılardır. Platformun desteklediği daha geniş kullanım yelpazesini görmek için Drupal ile neler yapılabilir yazımız çevredeki senaryoları özetler; Drupal nedir rehberimiz ise yapılandırılmış içerik modelinin temellerini ele alır.

Drupal ve Mobil Uygulama Hakkında Sıkça Sorulan Sorular

Son güncelleme: 17.08.2026 14:17