WooCommerce Mobil Uygulama: REST API, Eklenti Değişkenliği ve Barındırma

WooCommerce için mobil uygulama teklifi hazırlarken ilk sorduğumuz şey ürün sayısı ya da ekran listesi olmuyor: eklenti listesi oluyor. Sebebi basit. WooCommerce'ta iki mağaza birbirine benzemez; biri sade bir kurulumdur, diğerinde fiyatı bir eklenti hesaplar, kargoyu ikincisi belirler, checkout'a üçüncüsü alan ekler. Uygulamanın hangi işleri devralabileceği bu listeye bakılarak anlaşılır.

Bu yazı WooCommerce'a özgü tarafı anlatıyor: veri hangi uçlardan gelir, müşteri girişi neden çekirdekte hazır değildir, sepet tutarını kimin hesaplaması gerekir, barındırmanın uygulama hızıyla ilgisi nedir ve fiyatı hangi kalemler belirler. Teknoloji seçimi, mağaza inceleme süreci gibi ortak konuları mobil uygulama yaptırma rehberinde yazdık.

WooCommerce mobil uygulama veriyi nereden okur?

WooCommerce dışarıya REST uçları açar. Kabaca iki grup vardır ve karıştırılmaları en sık yapılan mimari hatadır.

• Yönetim tarafındaki uçlar. Ürün, sipariş, müşteri, kupon ve raporlama verisi buradan okunur ve yazılır. Erişim, panelde üretilen bir anahtar çifti ile yapılır ve bu anahtar mağaza sahibinin yetkisini taşır. Yani bir müşterinin telefonundaki uygulamaya verilecek bir şey değildir.
• Vitrin tarafındaki uçlar. Sepet işlemleri, ürün listeleme ve kampanya hesaplamasının müşteri adına yapılabildiği uçlar. Bunlar herkese açık çalışır ve oturum bilgisiyle ilerler.

Doğru mimari, uygulamanın hiçbir zaman yönetim anahtarını taşımaması ve bu anahtarın yalnızca kendi sunucunuzdaki servis katmanında durmasıdır. Uygulama sizin katmanınıza konuşur, katman WooCommerce ile konuşur. Bu ayrım hem güvenlik hem de hız için gerekli; hız kısmına birazdan geliyoruz.

Müşteri girişi çekirdekte hazır gelmez

Shopify veya ikas gibi altyapılarda müşterinin uygulamada oturum açması standart bir akıştır. WooCommerce'ta durum farklı: yönetim tarafındaki REST erişimi mağaza sahibi içindir, müşterinin kendi hesabıyla giriş yapabilmesi için ayrı bir kimlik doğrulama yolu kurulması gerekir. Bu, projede ayrı bir kalemdir ve teklifte görünmüyorsa muhtemelen atlanmıştır.

Burada iki yanlış yol var. Birincisi, uygulamanın kendi kullanıcı tablosunu kurup WordPress kullanıcısıyla hiç ilgilenmemesi. Bu durumda aynı kişi sitede bir, uygulamada başka bir kayıt olur; sipariş geçmişi bölünür, adres defteri ikiye ayrılır ve müşteri hizmetleri iki ekrana bakmak zorunda kalır. İkincisi, giriş işini uygulamanın içine gömülü bir yönetim anahtarıyla yapmaya çalışmak; bu, paket çözüldüğünde mağazanın tamamının açılması demektir.

Doğru kurgu, kullanıcı kaydının WordPress tarafında tekil kalması ve uygulamanın yalnızca bir oturum jetonu taşımasıdır. Böylece parola sıfırlama, e-posta doğrulama ve hesap silme akışları tek yerden yürür. Hesap silme özellikle önemli: uygulama içinden hesap açılabiliyorsa silinebilmesi de gerekiyor ve bu silmenin WordPress kullanıcısına işlemesi bekleniyor.

Sepet tutarını kim hesaplıyor? WooCommerce'ta asıl soru bu

WooCommerce kurulumlarında fiyatlandırma mantığı nadiren tek yerdedir. Miktar indirimi bir eklentiden, kullanıcı rolüne özel fiyat ikincisinden, kargo kuralları üçüncüsünden, vergi hesabı ayarlardan, kupon davranışı bir başka eklentiden gelir. Bunların toplamı, mağazanın sepet hesabında birleşir.

Uygulama bu tutarı kendisi hesaplamaya kalktığında iki şey olur. Kısa vadede bazı senaryolarda yanlış tutar çıkar; müşteri uygulamada bir fiyat, ödeme adımında başka bir fiyat görür. Uzun vadede daha kötüsü olur: her eklenti güncellemesinden sonra hesaplamanın hâlâ doğru olup olmadığını kontrol etmek sizin işiniz haline gelir. Bu, kimsenin sürdüremediği bir bakım yüküdür.

Bu yüzden kural nettir: sepet tutarı mağazanın kendi hesabıyla üretilmeli. Uygulama sepeti mağaza tarafında oluşturur, indirim, kargo ve vergi satırlarını okur ve gösterir. Bir kampanya eklentisi kurduğunuzda uygulamada hiçbir şey yapmanız gerekmemesinin sebebi budur.

Ödeme adımı: checkout'u uygulamada yeniden yazmayın

WooCommerce'ta checkout, eklentilerin en yoğun müdahale ettiği yerdir. Fatura tipi seçimi, TC kimlik alanı, kurumsal fatura bilgileri, kargo günü seçimi, hediye notu, kapıda ödeme koşulları; bunların hepsi çoğu mağazada eklentilerle eklenmiştir. Uygulama içinde bu alanların birebir kopyasını çıkarmak mümkündür ama ilk eklenti güncellemesinde tutarsızlık başlar.

Pratikte işe yarayan kurgu şudur: sepet ve ürün seçimi uygulama içinde native ekranlarla yürür, ödeme adımı mağazanın kendi ödeme akışında, uygulama içinde açılan bir görünümde tamamlanır. Oturum devredildiği için kullanıcı yeniden giriş yapmaz; ödemesini bitirir ve uygulamaya döner. Böylece taksit tablosu, kupon doğrulaması, kargo ücreti ve vergi hesabı tek yerde kalır.

Fiziksel ürün satan e-ticaret uygulamalarında mağazaların uygulama içi satın alma zorunluluğu bulunmadığı için tahsilat mevcut ödeme altyapınızdan geçmeye devam eder. Buradaki tek dikkat noktası, ödeme görünümünün uygulama içinde bir web sayfası gibi değil, akışın doğal bir parçası gibi durmasıdır; kullanıcı tarayıcıya atıldığını hissettiğinde terk oranı yükselir.

Barındırma: her istek WordPress'i baştan ayağa kaldırır

WooCommerce tarafında az konuşulan ama uygulama hızını doğrudan belirleyen konu bu. Bir REST isteği geldiğinde sunucu WordPress'i, aktif eklentileri ve temayı yükler, ardından isteği yanıtlar. Bu, hazır bir veri servisinden veri okumaya göre belirgin şekilde pahalı bir iştir. Eklenti sayısı arttıkça maliyet artar.

Uygulama her ekran için doğrudan siteye gidiyorsa sonuçlar şunlar olur: liste ekranları yavaş açılır, kampanya günlerinde sunucu zorlanır ve bu yük sitenin kendi ziyaretçilerine de yansır. Paylaşımlı barındırmada tablo daha da kötüleşir.

Çözüm, araya önbellek tutan bir servis katmanı koymaktır. Katalog, kategori ve arama sonuçları bu katmandan servis edilir; stok ve fiyat gibi kritik veriler ise sipariş anında kaynaktan doğrulanır. Senkron, sabit aralıklı tam tarama yerine webhook ile olay bazlı yapılır: sipariş, ürün ve stok değiştiğinde ilgili kayıt tazelenir. Bu kurgu hem uygulamayı hızlandırır hem sitenizin üzerindeki yükü azaltır.

WooCommerce uygulama entegrasyonu: sorumluluk dağılımı

WooCommerce mağaza uygulaması: hangi ekranlar yeniden düşünülür?

Bir WooCommerce mağaza uygulaması, WordPress temanızın mobil görünümünün kopyası değildir. Uygulamada ayrıca kurgulanması gereken başlıklar:

1. Ürün özellikleri ve nitelikler. Woo'da nitelik yapısı esnektir ve zamanla dağınıklaşır; aynı özellik farklı ürünlerde farklı adla girilmiş olabilir. Uygulamada filtrelerin işe yaraması için bu sözlüğün tekilleştirilmesi gerekir.
2. Değişkenli ürünler. Varyasyon kombinasyonları uygulamada alt panelden seçilmeli, stokta olmayan kombinasyonlar seçilemez şekilde işaretlenmelidir. Web'de açılır listeyle geçiştirilen bu adım mobilde satışı doğrudan etkiler.
3. Arama. WordPress'in yerleşik araması mobil kullanımın gerektirdiği toleransı vermez. Aramanın servis katmanında çalışması, yazım hatasını affetmesi ve yazarken öneri sunması gerekir; katalog genişse anlam tabanlı arama bu tarafta belirgin fark yaratır.
4. Blog ve içerik sayfaları. WooCommerce mağazalarının çoğu aynı zamanda içerik üretir. Uygulamada içeriği tamamen dışarıda bırakmak da her yazıyı taşımak da hatalıdır; ürünle ilişkili içeriği ürün ekranına bağlamak en verimli yol.
5. Sipariş takibi. Uygulamanın en sık açılan ekranıdır; alt sekmelerden birinde durmalıdır.

WooCommerce mobil uygulama yaptırmak: önce envanter

WooCommerce mobil uygulama yaptırmak isteyen bir mağazada ilk iş, kurulumun envanterini çıkarmaktır. Görüşmeye şu bilgilerle gelmek teklifin gerçekçi olmasını sağlar:

Bir de sürdürülebilirlik tarafı var. WooCommerce'ta uygulamanın uzun ömrü, güncelleme disiplinine bağlı: WordPress çekirdeği, WooCommerce ve eklentiler güncellendiğinde veri yapısı değişebilir. Hazırlık ortamında denenmeyen bir güncelleme, uygulamayı sessizce bozabilir. Bu bakım gerçeğini altyapı seçimi aşamasında değerlendirmek isteyenler için e-ticaret sitesi kurmak, satın almak ve kiralamak karşılaştırmasına bakmak faydalı olur.

WooCommerce mobil uygulama fiyatları neye göre oluşuyor?

• Eklenti karmaşıklığı. Bütçeyi en çok hareket ettiren kalem. Sepet ve checkout'a müdahale eden her eklenti ek inceleme, uyarlama ve test demek.
• Kimlik doğrulama kurulumu. Müşteri girişi çekirdekte hazır olmadığı için ayrı bir kalem olarak planlanır.
• Servis katmanı ve önbellek. Uygulamanın hızını ve sitenin yükünü belirleyen yapı; kurulumu ve izlemesi ayrı iştir.
• Barındırma iyileştirmeleri. Bazı kurulumlarda uygulama öncesi sunucu tarafında düzenleme gerekir; bu, uygulama bütçesinin dışında ama projenin içinde bir kalemdir.
• Tasarım derinliği. Şablon uyarlama ile markaya özel ekran kurgusu arasında ciddi emek farkı var.
• Bildirim kurgusu. Toplu duyuru basittir; davranışa göre segmentli gönderim ayrı bir sistemdir.
• Bakım. Woo tarafında bakım, diğer altyapılara göre daha kritik; çünkü değişen yalnızca işletim sistemleri değil, eklenti ekosistemi.

Teklif karşılaştırırken sorulacak soru şu: uygulama sepeti nerede hesaplıyor ve kullanıcıyı nerede tutuyor? Kendi tarafında kopya tutan çözümlerin operasyonel bedelini e-ticaret mobil uygulaması yazısında ayrıntılı yazdık.

Siteye bağlı uygulama mı, sıfırdan isteğe özel uygulama mı?

Birinci iş kolumuz bu yazının konusu: mevcut WooCommerce mağazanızın üzerine kurulan, kullanıcı ve sipariş verisini siteyle ortak tutan uygulama. Burada WordPress iş kurallarının sahibidir; uygulama, servis katmanı üzerinden aynı veriyi mobil deneyime çevirir.

İkinci iş kolumuz, WordPress'in veri modeline sığmayan işler: üyelik ve randevu sistemleri, saha ekibi araçları, bayi sipariş uygulamaları, cihazla konuşan uygulamalar. Burada uygulamanın kendi sunucu tarafı ve veri modeli sıfırdan yazılır. WooCommerce kullanan işletmelerde bu ikinci kol sık gündeme geliyor; çünkü siteye eklenti üstüne eklenti kurarak çözülmeye çalışılan operasyonel ihtiyaçlar bir noktadan sonra ayrı bir yazılım gerektiriyor. Bu ayrımın kapsam ve süreç tarafını mobil uygulama hizmet sayfamızda ayrıntılandırdık.

Sık karşılaşılan sorunlar

Özet

WooCommerce'ta mobil uygulamanın kaderini üç karar belirliyor. Birincisi, yönetim anahtarının uygulamaya değil kendi sunucunuza konması ve müşteri girişinin ayrı bir kalem olarak planlanması. İkincisi, sepet tutarının mağazanın kendi hesabıyla üretilmesi; çünkü Woo kurulumlarında fiyat mantığı eklentilere dağılmıştır ve uygulamada kopyalanamaz. Üçüncüsü, araya önbellek tutan bir katman koyarak her isteğin WordPress'i baştan ayağa kaldırmasını engellemek. Bu üçü doğru kurulduğunda kullanıcı kaydı tekil kalır, sipariş tek akışta ilerler ve eklenti güncellemeleri uygulamayı devirmez. Bildirim tarafını kurgularken push bildirim yazısındaki izin ve frekans dengesine bakın. Kurulumunuzun uygulamaya hazır olup olmadığını konuşmak isterseniz destek@stools.digital adresinden yazabilirsiniz.