Shopify Hydrogen mı Next.js mi? Karar rehberi
Kısa yanıt
Shopify, Storefront API erişimi için Hydrogen şartı koşmaz: API farklı ön yüz araçlarıyla çalışır. Hydrogen’ın belgelenmiş Shopify iş akışı ve Oxygen’la yayına alma modeli ihtiyaçlarınıza uyuyorsa Hydrogen’ı seçin; Next.js kullandığınız teknoloji yığınına uyuyorsa, Shopify entegrasyonunu ve yayına alma ayrıntılarını kendi dokümantasyonunda kontrol ettikten sonra onu değerlendirin. Her iki durumda da API erişimini, çalışma ortamı gereksinimlerini ve vitrinin bakımını kimin yapacağını doğrulayın.
- Storefront API, Shopify’ın özel bir alışveriş deneyiminde ticaret yeteneklerine erişmek için sunduğu arayüzdür ve belirli bir ön yüz framework’ü gerektirmez.
- Shopify, Storefront API’yi özel bir alışveriş deneyimi kurarken Shopify yönetim panelinde yönetilen ticaret verilerini kullanmanın bir yolu olarak tanımlar.
- API; ürün ve koleksiyonları göstermek, sepet işlemleri ve bağlama göre fiyatlandırma gibi yetenekler sunar.
- Shopify, Hydrogen için belgelenmiş bir yol sunar: Hydrogen uygulaması bir GitHub deposu üzerinden vitrine bağlanır ve vitrinin, yayınları barındıran ortamları olur.
- Vitrin akışı üzerinden bir Hydrogen uygulaması oluştururken geliştirici bir Hydrogen şablonundan başlayabilir ve JavaScript ya da TypeScript seçebilir.
Framework etiketleriyle değil, uygunlukla başlayın
Storefront API, Shopify’ın özel bir alışveriş deneyiminde ticaret yeteneklerine erişmek için sunduğu arayüzdür ve belirli bir ön yüz framework’ü gerektirmez. Yani ilk soru, Shopify’ın Hydrogen’la mı Next.js’le mi çalıştığı değil; framework’ün, entegrasyon iş akışının, yayına alma modelinin ve bakım sorumluluğunun işletmeyi düşündüğünüz vitrine uyup uymadığıdır.
Shopify, Storefront API’yi özel bir alışveriş deneyimi kurarken Shopify yönetim panelinde yönetilen ticaret verilerini kullanmanın bir yolu olarak tanımlar. API; ürün ve koleksiyonları göstermek, sepet işlemleri ve bağlama göre fiyatlandırma gibi yetenekler sunar. Bu ortak ticaret arayüzünü başlangıç noktası olarak alın, sonra her ön yüz iş akışının ekibinizden neler isteyeceğini karşılaştırın.
Uygulama yaklaşımlarını karşılaştırmadan önce vitrin gereksinimlerini yazın. Müşteri yolculuklarını, veri ve kimlik doğrulama ihtiyaçlarını, yayına alma ortamını, kullandığınız mühendislik araçlarını, yayınlardan ve süregelen düzeltmelerden sorumlu kişileri ekleyin. Böylece kimse, gereken çalışma modelini destekleyip desteklemediğine bakmadan yalnızca tanıdık olduğu için bir framework seçmez.
Next.js için varsayımları doğrulama sorularına çevirin: ekibiniz Storefront API’ye nasıl bağlanacak, sunucu tarafı işler nerede çalışacak, yayına alma ve gizli anahtarlar nasıl yönetilecek ve hangi çalışma ortamı kısıtları önemli? Cevapları framework’ün adından yetenek çıkarmak yerine Next.js’in ve barındırma hizmetinin güncel dokümantasyonuyla karşılaştırın.
Shopify’ın Hydrogen iş akışı neleri kapsar?
Shopify, Hydrogen için belgelenmiş bir yol sunar: Hydrogen uygulaması bir GitHub deposu üzerinden vitrine bağlanır ve vitrinin, yayınları barındıran ortamları olur. Vitrinin yaşam döngüsünün ne kadarını Shopify’ın belgelenmiş araçlarının karşılamasını istediğinizi karşılaştırırken bu iş akışını somut bir referans olarak kullanın.
Vitrin akışı üzerinden bir Hydrogen uygulaması oluştururken geliştirici bir Hydrogen şablonundan başlayabilir ve JavaScript ya da TypeScript seçebilir. Elinizde bir kod tabanı varsa, bir şablondan mı başlayacağınıza yoksa bir depo mu bağlayacağınıza karar vermeden önce bugünkü yapınızın ve araçlarınızın ne kadarının taşınabileceğine bakın.
Bir Hydrogen vitrini bir GitHub deposu üzerinden tek bir Hydrogen uygulamasına bağlanır; vitrinlerin yayınları içeren birden fazla ortamı olabilir. Var olan bir depo bir Hydrogen vitrinine bağlandığında Shopify, Oxygen’a yayına alma iş akışı için bir pull request açar; bu pull request birleştirildiğinde Oxygen’a sürekli yayına alma başlar.
Oxygen, Hydrogen vitrinlerini edge’de barındırmak için worker tabanlı bir çalışma ortamıdır. Bu iş akışı ekiplere değerlendirebilecekleri belirli bir yayına alma yolu sunar; ama bir gereksinim incelemesinin yerini tutmamalıdır. Herhangi bir yayına alma yolunu canlıya hazır saymadan önce ortamları, yayın onaylarını, gizli anahtarları, izlemeyi ve geri alma sorumluluğunu çıkarın.
Shopify entegrasyonunu ve API erişimini karşılaştırın
Framework’leri vitrinin gerçekten ihtiyaç duyduğu ticaret özellikleriyle karşılaştırın, ardından her özelliğin hangi API erişimini ve token kurulumunu gerektirdiğini belirleyin. Bu, sık yapılan bir planlama hatasını önler: “Storefront API çalışıyor” bilgisini her müşteri yolculuğunun aynı erişim modeliyle uygulanabileceğinin kanıtı saymak.
Token’sız Storefront API erişimi; ürünler, koleksiyonlar, satış planları, arama, sayfalar, bloglar, makaleler ve sepet okuma/yazma için erişim token’ı olmadan sorgu yapılmasına izin verir; sorgu karmaşıklığı sınırı 1.000’dir. Bu kapsamı özellik listenizle karşılaştırın ve her biri tek tek gerekli olan alanların birlikte sığacağını varsaymak yerine, istekleri şekillendirirken sorgu karmaşıklığını doğrulayın.
Bazı Storefront API yetenekleri token tabanlı kimlik doğrulama gerektirir: ürün etiketleri, metaobject’ler ve metafield’lar (meta alanlar), Online Store gezinme menüleri ve müşteriler. Token gerektiren işlerin uygulamanın geç bir aşamasında ortaya çıkmaması için bu gereksinimleri mimaride açıkça işaretleyin.
Shopify’ın özel (private) Storefront API token’larıyla ilgili rehberini de göz önünde bulundurun. Hangi ön yüzü seçerseniz seçin, özel kimlik bilgilerinin nerede duracağına ve geliştiricilerin bunları yanlışlıkla tarayıcıya giden koda, kayıtlara ya da paylaşılan yapılandırmaya koymaktan nasıl kaçınacağına karar verin.
Headless kanalı, özel bir uygulama gerektirmeden headless ve kendi barındırdığınız Hydrogen deneyimlerini destekler; Storefront API token’larını ve birden fazla özel vitrini oluşturup yönetebileceğiniz bir yer sunar. Ürün yayınlama, sipariş atfı ve satış raporlaması gibi kanal özelliklerini de içerir; sipariş atfı kanal düzeyindedir. Bir mağazada en fazla 100 etkin vitrin ve erişim token’ı olabilir.
Bu ayrıntıları yalnızca API kapsamını değil, operasyonel uygunluğu kontrol etmek için kullanın. Erişim token’larını kimin oluşturup yenileyeceğini, bir vitrinin yayınlama ve raporlamada nasıl temsil edileceğini ve planladığınız vitrinlerle token’ların belgelenmiş sınıra sığıp sığmadığını çıkarın. İşi ekipler ya da ortamlar arasında bölmeden önce bu sorumlulukları netleştirin.
Yayına alma ve çalışma ortamı sorumluluklarını karşılaştırın
Yayına alma uygunluğu, “şu framework’ü barındırmak daha kolay” gibi genel bir iddiayla değil; uygulamanızın ihtiyaç duyduğu çalışma ortamıyla ve ekibinizin üstlenmeye hazır olduğu işle ilgilidir. Hydrogen ve Oxygen’ın belgelenmiş kurulumunu somut bir seçenek olarak kullanın; Next.js’in çalışma ortamı, barındırma ve yayına alma ayrıntılarını ise düşündüğünüz kurulumun tam dokümantasyonuyla doğrulayın.
Hydrogen projeleri varsayılan olarak yerel bir geliştirme sunucusu içerir ve bu sunucu Oxygen’ın canlı çalışma ortamını yakından taklit eder; ikisi de Cloudflare’in açık kaynak workerd projesine dayanır. Böylece yerel geliştirme ile canlı ortam arasındaki ilişki belgelenmiş olur; yine de yalnızca yerelde çalıştırmaya güvenmeyin, projenin gerçek entegrasyonlarını ve yayına alma yapılandırmasını test edin.
Oxygen’ın desteklediği JavaScript standart web API’lerine de bakın. Bir çalışma ortamına bağlanmadan önce belirli bir sunucu ya da platform davranışını varsayan bağımlılıkların ve uygulama kodunun envanterini çıkarın, sonra bu varsayımları hedef ortamda test edin.
Oxygen Cache API’nin de belirli kısıtları vardır: caches.default API’sini desteklemez ve doğrudan Cache API işlemleri HTTPS istek URL’leri gerektirir. Önbellek vitrin için merkezi önemdeyse gereken önbellek işlemlerini erkenden test edin ve yerel geliştirme ile canlı ortamdaki beklenen davranışı belgeleyin.
Kendi barındırdığınız bir Hydrogen kurulumu ya da bir Next.js seçeneği için gerçek çalışma modelini karşılaştırın: altyapı yapılandırması, yayına alma yetkileri, gizli anahtarlar, çalışma ortamı yükseltmeleri, olay müdahalesi ve yayın kontrolleri kimin sorumluluğunda? Cevap, ekibin oturmuş iş akışını sürdürmekten yana olabilir; o akış vitrinin ihtiyaçlarını karşılamıyorsa farklı bir iş akışına geçmeyi de haklı çıkarabilir.
API bakımını ve ekip sahipliğini hesaba katın
Headless bir vitrin, yayından sonra da işletilmesi ve bakımı yapılması gereken bir sistemdir; bu yüzden API bakımını, yayına alma sahipliğini ve bilgi aktarımını framework kararına dahil edin. İşi, bir ticaret değişikliğinden test edilmiş ve yayına alınmış bir müşteri deneyimine kadar uzanan görevleri izleyerek tahmin edin ve her devir için sorumlu kişiyi ya da ekibi belirleyin.
Storefront API sürümlüdür, yılda dört kez yeni sürüm çıkarır ve Shopify istekleri her çeyrekte en güncel kararlı sürüme yükseltmeyi önerir. Sürüm incelemesini ve istek testlerini ekibin bakım sürecine ekleyin ve bir güncelleme acil hâle gelmeden önce ekibin değişiklikleri nasıl fark edip değerlendireceğine karar verin.
Ardından framework ne olursa olsun kalan operasyonel işi karşılaştırın: API erişimini gözden geçirmek, kimlik bilgilerini korumak, vitrin yolculuklarını test etmek, yayına alma davranışını doğrulamak ve kod tabanını onu destekleyecek kişiler için anlaşılır tutmak. Ekibin bugünkü becerilerine uyan bir teknoloji yığını devirleri azaltabilir; ama yalnızca ekip vitrinin çalışma ortamı ve ticaret gereksinimlerini de karşılayabiliyorsa.
Next.js için Shopify entegrasyon yaklaşımını ve hedef ortamınızla ilgili yayına alma ve çalışma ortamı ayrıntılarını doğrulayın. Karşılaştırmayı kanıta dayalı tutun: dokümantasyonun neyi teyit ettiğini, ekibinizin neyi test ettiğini ve hangi soruların hâlâ bir prototip ya da mimari karar gerektirdiğini kaydedin.
Karar listesi: teknoloji yığınını vitrine göre seçin
Ön yüzü, vitrinin gereksinimlerini entegrasyon yoluyla ve ekibin çalışma modeliyle eşleştirdikten sonra seçin. Bu listeyle tartışmayı, uygulamaya girişmeden önce doğrulayabileceğiniz kararlara dönüştürün.
- Vitrinin desteklemesi gereken ticaret yeteneklerini ve müşteri yolculuklarını listeleyin; her birini gereken Storefront API erişimi ve kimlik doğrulamasıyla eşleştirin.
- Ekibin ön yüz becerilerini, depo kurallarını, yayın sürecini ve süregelen bakımın sahibi olacak kişileri kaydedin.
- Hydrogen için uygulamayı, depoyu, ortamları ve Oxygen ya da kendi barındırdığınız yayına alma iş akışını gereksinimlerinizle karşılaştırın.
- Next.js için Shopify entegrasyonu, çalışma ortamı, barındırma, yayına alma ve gizli anahtar yönetimi ayrıntılarını ilgili dokümantasyonda doğrulayın.
- Çalışma ortamı varsayımlarını belirleyin ve gereken API’leri, önbellek davranışını ve yayına alma yapılandırmasını hedef ortamda test edin.
- Token güvenliği, API sürüm incelemesi, vitrin yayınları ve süregelen destek için sahipleri belirleyin.
Sık sorulan sorular
- Storefront API’yi kullanmak için Shopify Hydrogen şartı koşar mı?
- Hayır. Storefront API farklı platformlarda ve farklı ön yüz araçlarıyla özel ticaret deneyimlerini destekleyebilir; bu yüzden belirli bir framework gerektirmez.
- Hangi Storefront API yeteneklerine token olmadan erişilebilir?
- Token’sız erişim; ürünleri, koleksiyonları, satış planlarını, aramayı, sayfaları, blogları, makaleleri ve sepet okuma/yazmayı kapsar; sorgu karmaşıklığı sınırı 1.000’dir. Ürün etiketleri, metaobject’ler ve metafield’lar, Online Store gezinme menüleri ve müşteriler gibi yetenekler token tabanlı kimlik doğrulama gerektirir.
- Bir ekip Oxygen’ı ya da kendi barındırdığı bir Hydrogen kurulumunu seçmeden önce neyi doğrulamalı?
- Kodunuzun dayandığı çalışma ortamı davranışını, yayına alma ve gizli anahtar yönetimi iş akışını ve yayınların ve desteğin kimin sorumluluğunda olacağını kontrol edin. Oxygen’ın çalışma ortamını ve amacını da göz önünde bulundurun.
- Bir ekip Storefront API sürümünü ne sıklıkla gözden geçirmeli?
- Shopify istekleri her çeyrekte en güncel kararlı Storefront API sürümüne yükseltmeyi önerir.
