Başsız bir uygulama, arka ucu ön uçtan ayırır. İş mantığı, veriler ve temel işlevsellik bir tarafta bulunur. Kullanıcı arayüzü ise başka bir tarafta bulunur. İkisi yalnızca API'ler aracılığıyla iletişim kurar.
Bu isim basit bir fikirden gelir. "Baş", sunum katmanıdır, yani kullanıcıların gördüğü kısımdır. Paketlenmiş kullanıcı arayüzünü kaldırdığınızda "başsız" bir sistem elde edersiniz. Arka uç hala işini yapar. Bu işi, ekranları kendisi render etmek yerine bir API aracılığıyla sunar.
Bu kılavuz, başsız bir uygulamanın ne olduğunu, ekiplerin bu kalıbı neden benimsediğini, kabul ettiğiniz ödünleşimleri ve onunla karıştırılan ilgili "başsız" terimlerden nasıl farklılaştığını açıklar. Ayrıca, uygulamanız başsız hale geldiğinde API sözleşmesinin neden en önemli varlık haline geldiğini de gösterir.
“Başsız” aslında ne anlama geliyor
Geleneksel bir uygulamada, arka uç ve ön uç tek bir birim olarak gönderilir. Sunucu veriyi tutar, mantığı çalıştırır ve ayrıca tarayıcının görüntülediği HTML'i oluşturur. Kullanıcı arayüzü ve mantık sıkıca bağlıdır.
Başsız bir uygulama bu bağlantıyı koparır. Arka uç, bir dizi API uç noktası haline gelir. Sayfalar yerine veri döndürür. Herhangi bir istemci bu uç noktaları çağırabilir: bir web uygulaması, bir mobil uygulama, bir akıllı TV, bir IoT cihazı veya başka bir arka uç hizmeti.
Mimari, tanımı gereği API önceliklidir. Her işlevsellik parçasına bir API aracılığıyla erişilebilir olması gerekir, çünkü API tek giriş yoludur. Geri dönülecek yerleşik bir ekran yoktur.
Bu tek kural, inşa etme şeklinizi yeniden şekillendirir. Ön uç artık birçok tüketiciden sadece biridir. Çekirdeğe dokunmadan onu değiştirebilir, yeniden inşa edebilir veya yenilerini ekleyebilirsiniz. Her iki taraf da kendi zaman çizelgesinde dağıtım yapar.
Ekipler neden başsız mimariye geçiyor
Ayrıştırma, size ne kazandırdığını görene kadar soyut gelebilir. Ekiplerin bu deseni seçmesinin pratik nedenleri şunlardır.
Çok Kanallı Teslimat
Tek bir arka uç her kanala hizmet edebilir. Mantığı bir kez yazarsınız, ardından aynı API'ler üzerinde bir web ön ucu, bir mobil uygulama ve bir iş ortağı entegrasyonu oluşturursunuz. Her istemci, yanıtı kendi bağlamına uygun şekilde işler.
Yeni bir kanal eklemek, sistemi yeniden mimarileştirmek değil, yeni bir API tüketicisi eklemek anlamına gelir. Bir sesli asistan veya bir kiosk, zaten var olan uç noktalara karşı başka bir arayan haline gelir.
Bağımsız Ekipler ve Dağıtımlar
Ön uç ve arka uç bir kod tabanını paylaştığında, ekipler bir yayın döngüsünü de paylaşır. Bir taraf diğerini bekler. Başsız mimari bu bağı ortadan kaldırır.
Bir ön uç ekibi, arka uç dağıtımı olmadan yeniden tasarım yapabilir. Bir arka uç ekibi, API sözleşmesi geçerli olduğu sürece kullanıcı arayüzünü bozmadan iç yapıları yeniden düzenleyebilir. Her iki taraf da kendi hızında ilerler.Yeniden Kullanım ve Esneklik
Aynı iş mantığı birden fazla ürünü destekler. Bir fiyatlandırma motoru, bir kimlik doğrulama hizmeti veya bir içerik mağazası bir kez oluşturulur ve her yerde yeniden kullanılır. Ayrıca ön uçta da özgürlük kazanırsınız. Arka uç, yanıtın nasıl işlendiğini önemsemediği için istediğiniz herhangi bir çerçeveyi seçebilirsiniz.
Bu esneklik, başsız mimarinin API öncelikli geliştirme gibi fikirlerin ve daha geniş çaplı yazılımın başsız hale geldiği ve API'nin ürün olduğu tezinin yanında yer almasının nedenidir. Kullanıcı arayüzü ayrılabilir olduğunda, gerçekte sattığınız ve desteklediğiniz şey API'dir.
Ödünleşimler
Başsız mimari bedelsiz değildir. Bu desen karmaşıklığı ortadan kaldırmaktan ziyade yerini değiştirir. Karar vermeden önce maliyetler konusunda dürüst olun.
Artık daha fazla hareketli parça çalıştırıyorsunuz. Bir yerine iki veya daha fazla dağıtılabilir. Daha fazla altyapı, daha fazla CI işlem hattı ve izlenecek daha fazla hizmet. Tek, basit bir web sitesi geliştiren küçük bir ekibin bunlara ihtiyacı olmayabilir.
Ayrıca ön ucun tamamına sahipsiniz. Geleneksel bir CMS veya çerçeve size şablonlar ve hazır render işlevselliği sunar. Başsız mimariye geçtiğinizde, sunum katmanını her kanal için kendiniz inşa edersiniz.
Bir de sözleşme sorunu var. Tek bir kod tabanında, bozucu bir değişiklik derleme anında hemen ortaya çıkar. Başsız bir ayrışmada ise, arka uçtaki bir değişiklik API'yi çağıran bir istemciyi sessizce bozabilir. Üretimde bir şeyler başarısız olana kadar bunu hiçbir şey durduramaz.
Bu son nokta en önemlisidir. API sözleşmesi, tüm sistemi bir arada tutan dikiş yeridir ve aynı zamanda kazara bozulması en kolay şeydir.
Başsız uygulama ve ilgili terimler
"Başsız" terimi birkaç farklı şeye eklenir. Hepsi aynı fikri paylaşır (paketlenmiş UI yok), ancak farklı katmanları tanımlarlar. Bunları karıştırmak, planlama konuşmalarında gerçek bir kafa karışıklığına neden olur. İşte net bir döküm.
Başsız uygulama
En geniş terim. Arka uç mantığını ön uç sunumundan ayıran ve işlevselliği API'ler aracılığıyla sunan herhangi bir yazılım için bir mimari desenidir. Tüm sisteminiz başsızdır. Bir web uygulaması, bir mobil uygulama ve bir hizmet hepsi onu tüketebilir.
Başsız API
Paketlenmiş bir kullanıcı arayüzü olmadan sunulan bir API. Bu, tüm bir mimariden ziyade tek bir bileşenin tanımına daha yakındır. Başsız bir API, başsız bir uygulamanın tüketicilerine sunduğu arayüzdür. Pratikte bu iki terim yoğun bir şekilde örtüşür; başsız uygulama sistemdir, başsız API ise ona açılan kapıdır.
Başsız CMS
Daha dar, içeriğe özel bir durum. Başsız bir CMS, içeriği bir arka uçta yönetir ve web sayfalarını kendisi render etmek yerine API'ler aracılığıyla sunar. Contentful, Sanity ve Strapi gibi araçlar buraya girer. Alanı içerik olan başsız bir uygulamadır. Kaldırdığınız "baş", geleneksel bir CMS'nin şablon motorudur.
Başsız tarayıcı
Bu farklı bir durumdur. Başsız bir tarayıcı, görünür bir pencere olmadan çalışan gerçek bir web tarayıcısıdır. Sayfaları işler, JavaScript çalıştırır ve normal bir tarayıcı gibi davranır, ancak onu bir komut satırından veya bir betikten kontrol edersiniz. Ekipler bunu otomatik test, ekran görüntüsü alma ve veri kazıma için kullanır. Playwright ve Puppeteer yaygın sürücülerdir. Paylaşılan kelimeye rağmen, bunun arka uç mimarisiyle hiçbir ilgisi yoktur.
Ortak nokta: dördü de grafiksel bir arayüzü bırakır ve kod aracılığıyla çalışır. Ancak başsız bir uygulama bir mimari, başsız bir API bir arayüz, başsız bir CMS bir içerik arka ucu ve başsız bir tarayıcı bir otomasyon aracıdır. Hassas şey için hassas terimi kullanın.
Başsız mimarinin bestelenebilir ve MACH ile buluştuğu yer
"Başsız" terimini genellikle "bestelenebilir" ve "MACH" ile birlikte görürsünüz. İlişkilidirler ancak aynı değillerdir.
Bestelenebilir mimari, bir sistemi bağımsız, değiştirilebilir hizmetlerden inşa etmek anlamına gelir. Her parça tek bir iş yapar ve API'ler aracılığıyla bağlanır. Başsız mimari bir ön koşuldur; bir ön ucu arka uca kaynaklanmışsa serbestçe değiştiremezsiniz.
MACH, Mikro Hizmetler (Microservices), API Öncelikli (API-first), Bulut Yerel (Cloud-native) ve Başsız (Headless) kelimelerinin baş harflerinden oluşur. Bu, modern, modüler yığınları tanımlamak için başsız mimariyi diğer üç fikirle birleştiren bir dizi prensiptir. Başsız, kısaltmanın bir harfidir; ön ucun ayrıştırıldığını ifade eden kısımdır.
Başsız bir uygulama oluşturmak için tam MACH yığınına ihtiyacınız yoktur. Ancak zaten başsız mimariye geçtiyseniz, bu bitişik desenler doğal sonraki sorulardır.
API sözleşmesi neden ürün haline gelir
İşte en önemli değişim bu. Başsız bir uygulamada API artık bir yan kapı değildir. Tek kapıdır. Her istemci ona bağlıdır. Sözleşme belirsiz, kararsız veya belgelenmemişse, her tüketici aynı anda zarar görür.
Bu, API'nizi bir ürün olarak ele almanın kalbidir. Tüketicileriniz, ister kendi mobil ekibiniz ister harici bir iş ortağı olsun, kullanıcılardır. API'nin şekli, güvenilirliği ve belgelendirmesi ürün deneyimidir. Açık, kararlı bir API sözleşmesi, bağımsız ekiplerin dikiş boyunca birbirine güvenmesini sağlar.
Bu nedenle tasarım öncelikli yaklaşım burada karşılığını verir. Sözleşmeyi uygulamayı yazmadan önce tanımlar, ekipler arasında üzerinde anlaşır ve ortak bir doğruluk kaynağına karşı geliştirme yaparsınız. Bunun iş akışınıza nerede uyduğunu görmek için API öncelikli, API tasarım öncelikli ve kod öncelikli yaklaşımları karşılaştırın. Güçlü API tasarım prensipleri, sistem büyüdükçe sözleşmeyi tutarlı tutar.
Bunu yanlış yapmanın maliyeti, tüketici sayısıyla birlikte artar. Bir istemci özensiz bir API'ye tahammül edebilir. Web, mobil ve iş ortakları genelinde beş istemci edemez. Sözleşmeye gösterdiğiniz disiplin, tüm başsız sistemi stabil tutan disiplindir.
Apidog gibi bir aracın yeri
API bir ürün haline geldiğinde, onu iyi tasarlamanız, test etmeniz, mocklamanız ve belgelemeniz gerekir. Bu, API kalite katmanıdır ve başsız mimarinin dar bir dilimini oluşturur. Apidog bu dilimde çalışır.
Kapsamı netleştirmek gerekirse: Apidog bir CMS, bir ticaret platformu, bir API ağ geçidi veya bir yük oluşturucu değildir. Başsız mimarinizi sizin için inşa etmez. Yaptığı şey, mimariyi bir arada tutan sözleşmeyi dürüst tutmanıza yardımcı olmaktır.
Pratikte bu birkaç şeye benzer. Sözleşmeyi görsel bir OpenAPI düzenleyicide tasarlarsınız, böylece kod oluşmadan önce her ekip aynı doğruluk kaynağını görür. Ön uç ekiplerinin arka uç hazır olmadan sözleşmeye göre geliştirme yapabilmesi için uç noktaları dinamik verilerle mocklarsınız. Bozucu bir değişikliği bir istemciye ulaşmadan önce yakalayan iddialarla otomatik test senaryoları yazarsınız ve bunları Apidog CLI ile CI'da çalıştırırsınız. Başsız API'nizin her tüketicisinin neyi çağıracağını tam olarak bilmesi için otomatik oluşturulmuş, etkileşimli belgeler yayınlarsınız.
Apidog REST, GraphQL, gRPC, WebSocket, SOAP ve Socket.IO'yu kapsar ve bir masaüstü uygulaması, bir web uygulaması ve bir CLI olarak çalışır. API kalite çalışmaları için birkaç seçenekten biridir. Önemli olan araç değildir. Önemli olan, başsız mimariye geçmenin sözleşme kalitesini birinci sınıf bir endişe haline getirmesi ve bu işin bir yerde yaşaması gerektiğidir.
Sıkça Sorulan Sorular
Başsız bir uygulama, tek sayfalık bir uygulama ile aynı mıdır?
Hayır. Tek sayfalık bir uygulama, sayfa yenilemeleri olmadan güncellenen bir web kullanıcı arayüzü olan bir ön uç desenidir. Başsız bir uygulama ise, mantığı sunumdan ayırma ile ilgili bir arka uç desenidir. Bir SPA genellikle başsız bir arka ucu tüketir, ancak bunlar farklı katmanları tanımlar.
Başsız bir uygulama oluşturmak için mikro hizmetlere ihtiyacım var mı?
Hayır. Başsız mimari, ön ucu arka uçtan ayırmakla ilgilidir, arka ucu dahili olarak nasıl yapılandırdığınızla değil. API'ler sunan tek bir monolitik arka uç ile başsız bir uygulama oluşturabilirsiniz. Mikro hizmetler ayrı bir seçimdir.
Başsız mimari her zaman geleneksel, bağlı bir uygulamadan daha mı iyidir?
Hayır. Başsız mimari operasyonel karmaşıklık ekler ve ön uç işini ekibinize yükler. Tek kanallı basit bir site için geleneksel, bağlı bir yığın genellikle daha hızlı inşa edilir ve daha ucuza çalışır. Başsız mimari, birden fazla kanalınız, bağımsız ekipleriniz veya güçlü yeniden kullanım ihtiyaçlarınız olduğunda karşılığını verir.
Başsız API ile başsız uygulama arasındaki fark nedir?
Başsız bir uygulama, arka uç mantığının sunumdan ayrıldığı tüm sistemdir. Başsız bir API ise, bu sistemin sunduğu arayüzdür. Gündelik kullanımda terimler örtüşür, ancak uygulama mimaridir ve API ona açılan kapıdır.
Başsız bir kurulumda API sözleşmesi neden bu kadar önemlidir?
Çünkü API, arka uç ile her istemci arasındaki tek bağlantıdır. Bozucu bir değişiklik derleme zamanında yüzeye çıkmaz, üretimde yüzeye çıkar. Açık, istikrarlı, iyi belgelenmiş bir sözleşme, sistem geliştikçe her tüketicinin çalışmaya devam etmesini sağlayandır.