01Sorun ve çözüm
Headless e-ticaret mimarisinde ön yüz, ticari motordan bir API katmanıyla ayrılır. Katalog, fiyat, stok, sepet ve sipariş kuralları arka uçta bir kez tanımlanır; web sitesi, mobil uygulama, kiosk ya da pazaryeri akışı bu kuralları aynı kaynaktan okur. Biz önce hangi kanalların gerçekten gerektiğini ve mevcut altyapınızın hangi parçasının korunabileceğini çıkarıyor, ayrıştırmayı buna göre adım adım planlıyoruz. Her mağazanın böyle bir yapıya ihtiyacı yoktur. Tek kanaldan satan ve standart kurallarla çalışan bir işletmede fazladan katman bakım yükünü artırır; böyle bir durumda daha sade bir kurulum öneriyoruz.
02Kimler için
Headless e-ticaret kimlerin işine yarar
Ayrıştırılmış mimari, birden fazla satış kanalı ya da yoğun içerik ihtiyacı olan mağazalarda karşılığını verir.
- Web sitesi ile iOS ve Android uygulamasının aynı sepet ve kampanya kurallarıyla çalışmasını isteyen perakende markaları
- Ürün sayfalarını hikâye, video ve rehber içerikle zenginleştiren ve içerik ekibini geliştiriciye bağımlı bırakmak istemeyen markalar
- Mağaza içi tablet, kiosk veya dijital ekranlarda çevrim içi kataloğu göstermek isteyen zincirler
- Mevcut ERP ya da sipariş yönetim sistemini korurken yalnızca vitrini yenilemek isteyen firmalar
- Kampanya dönemlerinde ani trafik yükselişi yaşayan ve vitrini bağımsız ölçeklemek isteyen mağazalar
- Farklı ülke ve dillerde, ayrı alan adlarıyla tek katalogdan satış yapan e-ihracat işletmeleri
03İhtiyaçlar
Headless e-ticaret yaptırmadan önce netleşmesi gerekenler
Ayrıştırma bir mimari karardır; ön yüzü yeniden yazmaya başlamadan önce aşağıdaki başlıklarda anlaşmak gerekir.
- 01
Ticari motorun seçimi
Sepet, fiyat ve sipariş mantığı için bulut tabanlı bir ticaret platformu, açık kaynak bir motor ya da tamamen özel bir arka uç kullanılabilir. Seçim; ürün kurallarının karmaşıklığına, ekibin yetkinliğine ve lisans tercihine göre yapılır.
- 02
İçerik ile katalog arasındaki sınır
Ürün adı, fiyat ve stok ticari motorda; kampanya metinleri, rehber yazıları ve vitrin düzenleri bir headless içerik yönetim sisteminde tutulur. Hangi alanın nerede yaşayacağı baştan belirlenmezse aynı bilgi iki yerde güncellenir.
- 03
Arama motoru görünürlüğü
Tamamen tarayıcıda çizilen bir vitrin, ürün sayfalarının taranmasını zorlaştırabilir. Sunucu tarafında oluşturma ya da önceden üretilmiş sayfalar, kanonik adresler ve yapılandırılmış veri bu yüzden ilk aşamada planlanır.
- 04
Önizleme ve yayın akışı
İçerik editörü bir kampanya sayfasını yayına almadan önce gerçek tasarımda görmek ister. Taslak önizleme, zamanlanmış yayın ve geri alma kurulmadan bu mimari ekibe kolaylık değil yük getirir.
- 05
Kademeli geçiş
Bütün mağazayı tek seferde değiştirmek yerine önce kategori ve ürün sayfaları yeni vitrine alınabilir, ödeme adımı bir süre eski altyapıda kalabilir. Bu yöntem riski dağıtır ama yönlendirme ve oturum paylaşımı için ayrıca planlama ister.
04Özellikler
Headless mimaride kurduğumuz katmanlar
Kapsam projeye göre değişir; çoğu kurulumda aşağıdaki parçalar birlikte ele alınır.
- 01
Vitrin uygulaması
Next.js veya Nuxt gibi çerçevelerle geliştirilen, sunucu tarafında oluşturulan ve kenar sunucularda önbelleğe alınan bir ön yüz. Tasarım sistemi bileşenlere bölünür; yeni bir kampanya bloğu bütün temayı etkilemeden eklenir.
- 02
API ağ geçidi ve veri birleştirme
Ticari motor, içerik sistemi, arama servisi ve stok kaynağından gelen veriler tek bir API katmanında birleşir. Vitrin ihtiyacı olan veriyi tek istekle alır, arka uçtaki bir değişiklik ön yüzü kırmaz.
- 03
Blok tabanlı kampanya düzenleyici
Pazarlama ekibi, önceden hazırlanmış bloklarla açılış ve koleksiyon sayfalarını kendisi kurar. Bloklar tasarım kurallarına bağlı kaldığı için marka görünümü sayfadan sayfaya dağılmaz.
- 04
Kanal bazlı kurallar
Aynı ürün mobil uygulamada farklı bir kampanyayla, mağaza kioskunda yalnızca o mağazanın stoğuyla gösterilebilir. Kurallar kanal anahtarına göre arka uçta tanımlanır.
- 05
Ayrı arama servisi
Algolia, Elasticsearch veya Meilisearch gibi bir arama servisi kataloğu indeksler; yazım hatası toleransı ve anlık filtre sonuçları vitrinden bağımsız ölçeklenir.
05Entegrasyonlar
Headless e-ticaret için bağlanan sistemler
Ayrıştırılmış yapıda her sistem kendi işini yapar; aradaki bağlantılar olay ve API tabanlı kurulur.
- 01
Ödeme kuruluşları
iyzico, PayTR ya da bankaların sanal POS'u ödeme adımında doğrudan çağrılır; kart verisi ne vitrinde ne de API katmanında tutulur.
- 02
ERP ve stok kaynağı
Logo, Mikro, Netsis veya Nebim gibi sistemlerdeki stok ve fiyat değişiklikleri bir kuyruğa yazılır ve ticari motora sırayla aktarılır.
- 03
İçerik yönetim sistemi
Strapi, Contentful ya da Sanity gibi bir headless CMS seçilebilir; tercih ekibin alışkanlığına ve barındırma beklentisine göre yapılır.
- 04
Kargo ve fatura
Sipariş kesinleşince anlaşmalı kargo firmanızda gönderi kaydı açılır, e-Arşiv ya da e-Fatura kesimi GİB'e bağlı özel entegratörünüz aracılığıyla tetiklenir.
- 05
Pazaryerleri ve ürün akışları
Aynı katalog Trendyol ve Hepsiburada gibi pazaryerlerine ve Google Merchant Center akışına buradan beslenir.
06Süreç
Headless e-ticaret hizmeti nasıl ilerler?
Adım 01
Analiz
İş akışınızı, kullanıcılarınızı ve mevcut sistemlerinizi dinleriz; kapsamı, öncelikleri ve kabul ölçütlerini yazılı hâle getiririz.
Adım 02
Tasarım
Ekran akışlarını ve veri modelini çıkarırız. Arayüzü sizinle gözden geçirip onay almadan geliştirmeye geçmeyiz.
Adım 03
Geliştirme
Kısa döngülerle çalışırız; her döngü sonunda çalışan bir sürümü test ortamında görürsünüz.
Adım 04
Test
İşlevsel testler, entegrasyon testleri ve temel güvenlik kontrolleriyle hataları yayından önce yakalarız.
Adım 05
Yayın
Sunucu, alan adı, yedekleme ve izleme ayarlarını yaparak canlıya alırız; ekibinize kısa bir kullanım eğitimi veririz.
Adım 06
Bakım
İsterseniz bakım ve destek anlaşmasıyla güncellemeleri, izlemeyi ve yeni geliştirmeleri sürdürürüz.
07Teknoloji
Performans, önbellek ve hata toleransı
Ayrıştırılmış yapının en sık sorunu, parçalardan biri yavaşladığında vitrinin de beklemesidir. Bunu önlemek için ürün ve kategori sayfalarını önbellekten sunuyor, fiyat ve stok gibi sık değişen alanları ayrı ve kısa ömürlü isteklerle tamamlıyoruz. Ticari motor bir süre yanıt vermezse vitrin açık kalır; yalnızca sepete ekleme adımı kullanıcıyı durumdan haberdar eder.
Devamını okuDaha az göster
API katmanında istek sınırlama, kimlik doğrulama belirteçleri ve servisler arası imzalı çağrılar kullanılır. Sipariş, stok ve fiyat değişiklikleri olay kaydına yazılır; bir entegrasyon düştüğünde kaybolan mesaj yeniden işlenebilir. Yönetim tarafında rol bazlı yetki ve işlem kaydı tutulur.
Barındırma için AWS, Azure veya Google Cloud ile vitrin için kenar ağ hizmetleri birlikte değerlendirilir. Mesafeli satış sözleşmesi, ön bilgilendirme formu ve çerez onayı ödeme akışında doğru adımda gösterilir; KVKK aydınlatma metni ve açık rıza kayıtları sipariş verisiyle ilişkilendirilir.
08Çalışma modelleri
Bu hizmette çalışma modelleri
- 01
Proje bazlı
Sabit kapsam, sabit fiyat ve belirli teslim tarihi
Kapsamı belli, teslim tarihi olan işler için.
- Yazılı kapsam ve kabul ölçütleri
- Sabit fiyat ve belirli teslim tarihi
- Teslim ve kabul adımları sözleşmede
- 02
Bakım ve destek
Aylık sözleşmeli, SLA'lı bakım, destek ve geliştirme saati
Yayındaki bir sistemin sürekliliği için.
- Aylık sözleşme ve SLA
- İzleme, güncelleme ve hata düzeltme
- Aylık geliştirme saati
09Sık sorulan sorular
Headless e-ticaret hakkında sık sorulan sorular
Headless e-ticaret yaptırmak mevcut sitemizi kapatmayı gerektirir mi?
Gerektirmez. Çoğu geçişte önce vitrin yenilenir; ticari motor ve ERP bağlantıları bir süre olduğu gibi kalır. Sayfa grupları hâlinde ilerleyen bir planla eski ve yeni yapı bir dönem birlikte çalışabilir.
Headless e-ticaret fiyatları neye göre değişir?
Kanal sayısı, seçilen ticari motor ve içerik sisteminin lisans modeli, entegre edilecek sistemler ve tasarım sisteminin kapsamı belirleyicidir. Birden fazla servisin izlenmesi gerektiği için bakım tarafını da teklifte ayrı bir kalem olarak yazıyoruz.
Hazır bir e-ticaret platformunu arka uç olarak kullanabilir miyiz?
Vitrin API'si sunan platformlar bu şekilde kullanılabilir. Bu durumda sepet ve ödeme kuralları platformun sınırları içinde kalır; özel bir bayi fiyatı ya da karmaşık kampanya kuralı gerekiyorsa araya ek bir servis yazmak gerekebilir.
Arama motorlarındaki görünürlüğümüz düşer mi?
Sayfalar sunucu tarafında ya da önceden oluşturulursa düşmesi için teknik bir neden yoktur. Asıl risk geçiş sırasında adreslerin değişmesidir; eski adresler kalıcı yönlendirmeyle yeni sayfalara bağlanır ve site haritası yeniden üretilir.
İçerik ekibimiz yeni yapıda nasıl çalışacak?
Editörler içerik yönetim sisteminde bloklarla sayfa kurar ve yayından önce gerçek tasarım üzerinde önizleme görür. Geliştiriciye yalnızca yeni bir blok türü gerektiğinde ihtiyaç duyulur.
Mobil uygulamayı vitrinle aynı anda geliştirmek zorunda mıyız?
Zorunda değilsiniz. API katmanı baştan çok kanallı tasarlanırsa mobil uygulama daha sonra aynı uç noktaları kullanarak eklenebilir; bu aşamada Flutter veya React Native gibi ortak kod tabanları değerlendirilebilir.
10İlgili hizmetler