Shopify Functions Gercekte Nasil Calisiyor: Plus Magazalarinin Hala Anlamadigi Wasm-at-Edge Mimarisi

Iki hafta once migration odakli Functions yazimiz LinkedInde beklenmedik sekilde iyi gitti. En cok begenilen yorum meselenin ozunu yakaladi: Scriptsden Functionsa gecis acik hikaye ama gercek hikaye mimari. Shopify Functions sadece syntax degisikligi ile gelen bir Scripts yerine gecimi degil. Platformda yepyeni bir runtime katmani — WebAssembly modulleri deterministik calisan checkout ve order processing ile edge uzerinde co-lokalize edilmis Scriptsin asla sahip olmadigi sert gecikme butceleri ve sandbox garantileri ile.

Bu yazi Functions Developer Guideina mimari follow-up. Onceki yazi taktikseldi — nasil migrate ederim API surface neler bir discount neye benziyor. Bu yazi kavramsal ve Plus magazalardaki senior muhendislere CTOlara ve engineering managerlara hitap ediyor — platformun neden boyle kuruldugunu runtimein iceride nasil calistigini ve modelin hangi tasarim kaliplarini mumkun kildigini ve hangi kaliplari bilincli olarak disladiklarini ogrenmek isteyen okur icin.

Buzzword yok. Milisaniye rakamlarini bellek sinirlarini ve somut tradeofflari aktariyoruz. Modelin zayif oldugu yerde soyleyecegiz. Shopifyin rakiplerden daha iyi bir tradeoff yaptigi yerlerde teknik olarak gerekceyi vereceyiz.

Runtime modeli: sert determinizm garantili Wasm sandbox

Shopify Functions Shopify tarafindan kontrol edilen bir host ortaminda calisan WebAssembly modulleridir. Dort sert teknik sinir runtime tanimlar ve dordu de bilincli olarak secilmistir.

• 5 MB binary siniri: Deploy edilen Wasm modulu en fazla 5 MB olabilir. Pratikte Rustla derlenmis bir discount fonksiyonu 80-400 KB gelir Javy ile derlenmis bir JS fonksiyonu 1.5-3 MB.
• Cagri basina 5 ms calisma butcesi: Sert ust sinir. 5 msyi gecmek function abortunu tetikler ve platform default davranisa duser (discount yok customization yok). Production fonksiyonlarinda tipik olarak 0.8-2.5 ms gozlemliyoruz.
• Fuel tabanli komut butcesi: Wall-clock zamanin ustune Shopify bir fuel sistemi kullanir (Wasmtime fuela benzer). Her Wasm komutu fuel tuketir. Sonsuz dongude takilan bir function fuel tahsisini yakar ve sonlandirilir — wall-clock daha dusuk olsa bile. Patolojik inputlara karsi koruma saglar.
• I/O ag cagrisi paylasilan state yok: Functionin fetchi yok dosya sistemi yok cagrilar arasi paylasilan bellege erisimi yok. Her calisma bos bellekle baslar bir GraphQL input snapshotu alir bir GraphQL output snapshotu uretir. Hepsi bu.

Bu dort sinir hata degil. Platformun guvenlik ve gecikme garantisi. Shopify her POPta 250 Plus tacirinin uc saniye timeoutlu fetch yapabilen function logiki calistirmasina izin verseydi checkout gecikmesi artik tahmin edilemez olurdu. Tum fonksiyonlari deterministik sinirli bir Wasm sandboxinda kilitleyerek platform hicbir kiracinin baska bir kiraciyi etkileyemeyecegini ve her checkout requestinin hesaplanabilir worst case latency profilinin oldugunu garanti edebiliyor.

Host functions ve imports/exports modeli

Cloudflare Workers veya Fastly Compute@Edge icin Wasm yazmis biri host functions kavramini bilir. Wasm sandboxinin kendisinin yetenegi yok — hesap yapabilir ama gozlemleyemez. Host ortami sandboxa fonksiyonun cagirabilecegi sinirli sayida imports sunar. Shopify cok az export eder: esas olarak shopify::function_input (GraphQL snapshotunu dondurur) ve shopify::function_output (sonuc olarak operasyonlari kabul eder). Ag icin host import yok http_get yok storage_read yok. Kasitli.

// Pseudocode: host function arayuzu (Shopify dahili)
extern "C" {
  fn shopify_function_input_read(buf: *mut u8, len: usize) -> i32;
  fn shopify_function_output_write(buf: *const u8, len: usize) -> i32;
  fn shopify_function_log(level: i32, buf: *const u8, len: usize);
}

Function Wasm linear memory icinde ne yapiyor — parsing iterasyon pattern matching matematik — platformu ilgilendirmiyor. Sandbox disina ne yapiyor — sadece output yazmak ve log yollamak — iki host cagrisina sinirli.

Neden Wasm da Cloudflare Workers gibi JavaScript isolate degil?

Cloudflare Workers V8 isolatelarda calisir. AWS Lambda container VMlerde calisir. Fastly Compute@Edge Lucet/Wasmtime ile Wasmda calisir. Shopify bunlardan herhangi birini secebilirdi. Wasmi sectiler ve gerekce saglam.

• Varsayilan deterministik: Wasmin yerlesik non-determinizm kaynagi yok. Math.random yok host import olarak acikca verilmedikce Date.now yok dosya sistemi zamani yok. Function calismalari tekrarlanabilir. Ayni input ayni outputu uretir. Compliance icin auditable olmak zorunda olan bir platform icin bu gercek bir deger.
• Varsayilan sandbox: Wasm modulleri sadece host ortaminin acikca izin verdigini yapabilir. V8 isolatelari sandboxingi JS API yuzeyinde uygulamak zorunda — tarihsel olarak side-channel sizintilarinin kaynagi (Spectre Meltdown). Wasm yetenek-temelli guvenli.
• Dil bagimsiz: Rust AssemblyScript TinyGo C C++ ve JS (Javy uzerinden) hepsi Wasma derlenir. Shopify kimseyi JSe zorlamaz — Rust DNAli ekipler Rust function yazar JS tercih eden ekipler JS yazar ve Javy uzerinden Wasm gonderir.
• Milisaniye soguk baslatma: Wasm modulleri V8 isolatelardan hizli container VMlerinden dramatik olarak hizli instantiate olur. Shopify yeni yuklenmis bir function 5 msnin altinda isitabilir — Lambdanin gerektirdigi pre-warming yuku yok.
• Platform seviyesinde guvenlik izolasyonu: 250 Plus taciri ayni fiziksel edge node uzerinde function calistirip hicbir kiraci digerini goremez. Wasm linear bellegi instance basina izole.

Tradeoff: Wasm JSden debug etmesi daha zor cunku stack tracelerin Wasm modul sembollerine gore okunmasi gerekiyor source dosyalarina degil. Shopify bunu Functions CLIindaki source mapler ve Partners dashboarduundaki Function Run loglari ile hafifletir.

Edge calisma topolojisi: functionlar gercekte nerede calisir

Functionlar merkezi bir veri merkezinde calismaz. Shopifyin edge POPlarinda calisir — checkout ve order processing servisleri ile co-lokalize. Berlinden bir cart guncellemesi Frankfurt POPa duser cart-transform function orada 2 msnin altinda calisir ve sonuc dogrudan checkout stateine yazilir. Torontoya round trip yok. Cross-region gecikme yok.

DACH tacirleri icin bu onemli cunku Frankfurt buyuk EU POPlarindan biri ve Berlinli bir checkout kullanicisi ile Frankfurttaki function calismasi arasindaki gecikme ilk hopta tipik olarak 8-25 ms. Takibini yaptigimiz Plus magazalarda p50 function gecikmesi 1.4 ms p99 3.8 ms goruyoruz.

Bu neden checkout conversion icin onemli? Yillardir suregelen arastirma her 100 ms ek checkout gecikmesinin conversion oranini yaklasik 0.5-1 puan dusurdugunu gosteriyor. Discount veya delivery logikini app backend yerine edgede calistirmak checkout sayfa yukleme basina gercek 200-600 ms tasarruf eder.

2026 function API surfaceleri — eksiksiz genel bakis

Functionlar tek endpoint degil. Her biri kendi GraphQL input semasi ve output operasyon seti olan birden fazla target APIdir. 2026 GA itibariyle:

• product_discounts: tek tek urun variantlarinda indirim. Klasik line-item Scriptslerin yerini alir. Scriptslerin asla yapamadigi kaliplari mumkun kilar — orn cart bilesimine duyarli tag tabanli tier logik.
• order_discounts: siparis toplaminda indirim. Order Scriptslerin yerini alir. Karmasik esik kurallarini destekler (orn bir kategorideki tum urunler uzerinden musteri tag kosulu ile).
• shipping_discounts: kargoda indirim. Free shipping esikleri musteri tier tabanli kargo iadeleri.
• delivery_customization: teslimat secenekleri filtrele yeniden adlandir yeniden sirala. Ornek: 50 kgin uzerindeki siparislerde standart kargoyu gizle sadece nakliye goster. Scriptslerde karsilik gelen hook yoktu.
• payment_customization: odeme yontemlerini filtrele yeniden adlandir yeniden sirala. Ornek: B2B musterilerinde Klarnayi gizle fatura goster. Risk tagli musterilerde PayPali kaldir.
• cart_transform: bundle logik virtual variant kompozit urun. Bu API eskiden cart attribute ve Liquid hack ile yapilan tum bir uygulama sinifinin yerini alir.
• cart_checkout_validation: checkoutta dogrulama kurallari. Ornek: yalnizca AB teslimat adresine izin ver belirli posta kodlarini blokla. Hatalar dogrudan checkoutta gosterilir.
• fulfillment_constraints: siparislerin locationlar arasi nasil bolundugunu kontrol eder. Ornek: mumkunse her seyi tek depodan gonder olmazsa tanimli onceliklerle coklu location boluntusu.
• order_routing: hangi location hangi order linei alir. Eski location-priority ayarlarindan daha karmasik logik.

Her APInin kendi GraphQL semasi kendi input typelari ve kendi output operasyonlari var. Shopify CLI uzerinden codegen yerel olarak semadan Rust veya TypeScript tipleri uretir. Bu function gelistirmesini tip guvenli yapar.

Input/output sozlesme modeli: snapshot gir operasyon cik

Bu tum mimarinin kavramsal olarak en onemli noktasi. Functionlar canli state uzerinde calismaz. Cart (veya orderin APIye gore) bir snapshotunu alir ve operasyon dondurur — yeni bir cart nesnesi degil bir degisiklik listesi.

// product_discounts function — basitlestirilmis
input FunctionInput {
  cart: Cart!
  shop: Shop!
  customer: Customer
  presentmentCurrencyRate: Decimal!
}

type FunctionResult {
  discounts: [Discount!]!
  discountApplicationStrategy: DiscountApplicationStrategy!
}

Neden bu tasarim? Cunku yaris durumlarini ortadan kaldirir. Scriptsler Ruby VMde senkron calisirdi ama yurutme sirasinda carti mutate edebilirlerdi — birden fazla Script calistiginda tanimsiz davranisa yol acardi. Functionlar donmus bir snapshot gorur operasyon dondurur ve Shopify bu operasyonlari iyi tanimlanmis bir sirada master statee uygular.

Bu ayrica functionlari yan etkisiz ve dolayisiyla cachelenebilir yapar. Ozdes input ozdes output garantiler. Partners dashboardundaki function replay ozelliginin temeli budur — Shopify her function calismasini orijinal input ile yerel olarak yeniden oynatabilir.

Bir magazada birden fazla functionin bestelenmesi

Bir Plus magaza ayni anda birden fazla functiona sahip olabilir. Iki discount function bir delivery customization bir payment customization ve iki cart validation function production setupinda normaldir.

Sira nasil belirleniyor? Uc seviye var.

• API sirasi: Platform once cart_transformi calistirir (cart yapisini mutate eder) sonra discount APIlerini (product order shipping) sonra delivery_customization ve payment_customizationi en son cart_checkout_validation. Bu sira deterministik ve dokumante.
• Bir API icinde: Discount application strategy (FIRST MAXIMUM ALL) birden fazla discount functionin nasil birlestigini kontrol eder. FIRST eslesen ilk indirimi alir MAXIMUM en yuksegi ALL hepsini ust uste yigar (dikkatli kullanin).
• Function basina: Tek bir function icinde kod operasyon dondurmek mi yoksa bos sonuc mu vermek istedigine karar verir. Hicbir sey dondurmeyen function etki yapmaz.

Pratikte 2026da temiz bir Plus mimari soyle gorunur: bundleler icin bir cart-transform function iki product-discount function (biri loyalty tier digeri promo code) harcama esikleri icin bir order-discount function carrier logiki icin bir delivery-customization B2B-vs-DTC ayrimi icin bir payment-customization ve compliance kurallari icin bir validation function (orn yalnizca AB teslimat).

State olmadan state yonetimi: standart kaliplar

Functionlar cagrilar arasi kalici state tutamaz. Plus ekipleri 2026da konfigurasyon ve harici veriye dayali karmasik logiki yine de nasil sevk ediyor?

• Konfigurasyon icin metafield: tier esikleri indirim yuzdeleri carrier kurallari haric tutulan posta kodlari shop product veya customer metafieldlarda yasar. Function inputta gelirler. Bir metafield degerini degistirmek bir sonraki function calismasini hemen etkiler.
• Harici veri zenginlestirmesi icin webhookla app backend: Functionin Shopifyda olmayan bir deger ihtiyaci varsa — orn harici ERPden anlik stok — app backend harici veriyi periyodik olarak Shopify metafieldlarina senkronlar. Function sadece metafieldi okur. Canli API cagrisi gerekmiyor.
• Function-functiona iletisim icin cart attribute: Bir cart_transform function sonraki bir discount functionun okudugu bir cart attribute kurabilir. Functionlar arasi state paylasiminin tek yolu budur.
• Kisisellestirme icin customer.metafield: Loyalty tier lifetime value tercih edilen kategoriler customer metafield olarak saklanir ve function tarafindan okunur.
• App Extensions uzerinden function settings UI: Bir function Shopify Adminde bir konfigurasyon UIi ile gelebilir. Ayarlar function-owner namespaceindeki metafieldlar olarak saklanir.

Gozlemlenebilirlik: productionda functionlari nasil izleriz

Functionlar Scriptslerin sahip olmadigi yerlesik bir gozlemlenebilirlik katmani ile gelir.

• Partners dashboardundaki Function Run loglari: Her function calismasi input output wall-clock zamani fuel tuketimi ve shopify.functionLog cagrilarindan loglari kaydeder. Function basina Partners dashboardunda aranabilir.
• shopify app function-runs CLI: shopify app function-runs son calismalari JSONla komut satirinda doner. Debug ve snapshot replay icin pratik.
• Replay ozelligi: Her function calismasi orijinal input ile yerel olarak yeniden oynatilabilir — shopify app function run --input run-2026-05-15.json. Acik ara en onemli debug workflow.
• Performans butceleri: Function basina p95 gecikme dashboardda gorunur. 4 msye dogru kayan bir function 5 ms tavanini patlatmadan once uyari sinyalidir.
• Output dogrulama: Function GraphQL semasina uymayan output donerse calisma basarisiz olur ve loglanir. API guncellemelerinde tip kaymasina karsi yardimcidir.

// ornek function_log ciktisi
{
  "run_id": "fn_run_01HABCDE",
  "function_id": "tier-discount-v3",
  "wall_ms": 1.42,
  "fuel_consumed": 14823,
  "input_bytes": 4192,
  "output_bytes": 312,
  "status": "success",
  "logs": ["customer tier: gold", "applied 15% discount"]
}

2026da Plus ekiplerine shopify app function-runs CLI ciktilarini Datadog veya Honeycomb gibi harici bir gozlemlenebilirlik platformuna pipe etmelerini oneririz. Bu p99 uyarisini ve cross-service korelasyonu mumkun kilar.

Wasm sandboxin guvenlik etkileri

Bir Plus taciri ucuncu taraf bir uygulamadan function yuklediginde — diyelim App Store partnerinden bir discount stacking uygulamasi — bu ucuncu tarafa checkout akisinda kod calistirma hakki verilmis olur. Scriptsde bu gercek bir tedarik zinciri riskiydi. Functionsla cok daha az problemli cunku function sert bir sandboxda calisiyor.

• Veri sizintisi yok: Function cart verisini ucuncu taraf sunucuya yollayamaz. Agi yok. App gelistiricinin kotu niyeti olsa bile cart verisini disari sizdiramaz.
• Lateral hareket yok: Function sadece APInin izin verdigi GraphQL inputu gorur. Ayni edge node uzerindeki diger musterilere diger siparislere diger magazalara erisim yok.
• Denial of servicee karsi sert limitler: Sonsuz dongudeki bir function fuelini yakar ve sonlandirilir. Checkoutu kilitleyemez.
• Auditable kod yuzeyi: Function paketleri App Storeda gorunur ve yuklemeden once guvenlik tarafindan incelenebilir. Scriptsle bu pratikte imkansizdi.

Plus compliance ekipleri icin bu gercek bir ilerleme. Danistigimiz enterprise Plus musterilerinde function tabanli bir uygulamanin guvenlik onay suresinin dort-alti haftadan (Scripts donemi) yaklasik iki haftaya dustugunu goruyoruz.

Plus tacirlerinin 2026da temiz sevk ettigi uc mimari kalip

Kalip A: cart-snapshot farkindalikli kademeli indirim yigma

Sorun: loyalty tier musterileri tier 1de 10 tier 2de 15 tier 3te 20 indirim alir. Bir de 5 promo code var. Kural: tier ile promonun yuksek olani uygulanir ayrica 80 EUR ustu cart toplaminda free shipping.

Scriptsle naif yaklasim: tum kosullar tek blokta olan bir order Script. Ceyrek basina uc degisiklikten sonra kimsenin anlamadigi conditional katmanina donusur.

Functions mimarisi: uc ayri function. Function 1 (product_discounts) tier indirimini her lineda uygular tieri customer.metafielddan okur. Function 2 (order_discounts) promo codeu cart attributedan kontrol eder tier indirimi ile karsilastirir discountApplicationStrategy MAXIMUM ile yuksek varianti dondurur. Function 3 (shipping_discounts) cart toplami 80 EUR ustu oldugunda kargoyu sifira ceker.

Neden daha iyi: her function bagimsiz test edilebilir bagimsiz versiyonlanabilir bagimsiz deploy edilebilir. Tier esik degisikligi bir metafield duzenlemesidir. Promo code davranis degisikligi bir function deploydur. Ortak kod yolu yok regresyon yuzeyi yok.

Kalip B: DACH lojistigi icin carrier farkindalikli teslimat kurallari

Sorun: 30 kg altinda DHL 30-150 kg arasi DPD 150 kg ustu nakliye express secenekleri sadece Almanya ve Avusturyada Isvicreye lityum iceren urunler icin kargo yok.

Shipping profile ile naif yaklasim: Shopify shipping ayarlarinda kurulan uc kargo bolgesi uc shipping profile — yaklasik bes urun kategorisine kadar olcelir sonra surdurulemez olur.

Functions mimarisi: bir delivery_customization function. Input variant metafieldlari dahil cart (agirlik kategorisi lityum bayragi). Function cart bilesimine ve hedef ulkeye gore mevcut kargo seceneklerini filtreler. Sonuc: cart basina temiz bir izin verilen carrier listesi.

Neden daha iyi: logik koda yaziliyor UIya degil. Kod versiyonlanabilir test edilebilir kod-review ile guvence altina alinabilir. Yeni bir kural (orn lityum icin SwissPost dislama) on tiklamali konfigurasyon yerine iki satirlik PRdir.

Kalip C: DACH icin compliance odakli odeme yonlendirme

Sorun: B2B firma musterileri Billie uzerinden fatura B2C musterileri Klarna Isvicreli musteriler TWINT 1.500 EUR ustu sepetler Klarnayi gizler (risk compliance) risk tagli customer.tag olan musteriler hicbir pay-later secenegi gormez.

Scriptsle naif yaklasim: bes if blokuyla payment Script. Uc ceyrek sonra surdurulebilirlik: kotu.

Functions mimarisi: bir payment_customization function. customer.tags customer.metafield (app backendin sync ettigi risk skoru) cart.totalAmount deliveryAddress.country okur. Odeme seceneklerinin yeniden siralanmasi ve filtrelenmesi input uzerinde saf bir functiondur. Testler snapshot dosyalarla unit-testable.

BigCommerce Salesforce Commerce Cloud commercetools ile karsilastirma

Bu katmanda diger commerce platformlari ne sunuyor?

• BigCommerce: GraphQL Storefront API ve webhooklar sunar ama karsilastirilabilir edge-Wasm katmani yok. Custom indirim logiki tipik olarak frontendde (headless) veya bir app backendde uygulaniyor. Baslamasi daha hizli ama gecikme ve guvenlik izolasyonu ayni aralikta degil.
• Salesforce Commerce Cloud: OCAPI hookleri ve SFRA var ama yurutme Salesforce veri merkezinde JVM containerinda — soguk baslatma gecikmesi daha yuksek ve dil (SFCC ISML JS) Wasm-cok-dilli kadar esnek degil.
• commercetools: harici functionlari tetikleyen API Extensions ve Subscriptions sunar — genellikle AWS Lambda. Ag erisiminde daha esnek ama daha yavas (soguk baslatma 100-500 ms) ve audit etmesi daha zor.
• Adobe Commerce: geleneksel PHP eklenti dunyasi karsilastirilabilir sandbox modeli yok.

Shopifyin tradeoffu acik: deterministik guvenli ucuz edge yurutmesi karsiliginda sert sinirlar (5 ms ag yok). Bir taciri gercekten canli API cagrisi gerekiyorsa (orn harici vergi hesaplamasi) Admin APIda app backend dogru katman olarak kalir. Functionlar her sey icin son soz degil.

Functionlarin 2026da hala yapamadiklari

Durust sinirlamalar:

• Ag yok: fetch yok harici API cagrisi yok PIM ERP veya vergi servisinden canli veri yok. Logik canli harici veri gerektiriyorsa app backendden webhook tabanli metafield sync ile yapilmali.
• Checkout UI degisikligi yok: Functionlar veriyi donusturebilir ama checkout UIini mutate edemez. Onun icin Checkout UI Extensions ayri bir primitiftir.
• 5 ms tavani sert: Yuzlerce cart iterasyonu veya buyuk veri yapisi olan karmasik algoritmalar butceyi patlatabilir. Deploydan once Function Runnerla profiling oneriyoruz.
• Real time pricing API yok: Harici fiyat motorundan dinamik fiyat (orn currency hedging servisi) dogrudan calismiyor — metafield snapshotu olarak hazirlanmali.
• Async operasyon yok: Functionlar senkron tek thread Promise.all yok worker pool yok.
• Sinirli input derinligi: GraphQL inputu derinlik ve line sayisinda sinirli. 500+ lineli cok buyuk B2B cartlar edge case tetikleyebilir.

Shopify nereye gidiyor: 2026 ve sonrasi

Function roadmapinde gordugumuz uc yon.

• Daha fazla API surface: fulfillment_constraints ve order_routing olgunlasiyor subscription pricing ve bundle constraints icin yeni APIler tartisma asamasinda. 2026/2027de 2-3 ek target API daha bekliyoruz.
• Hydrogen ve OXP ile yakinsama: Functionlar Hydrogen storefront dunyasiyla zaten entegre (Functionsdan gelen discount logiki Hydrogen cartinda saygi goruyor). Hydrogen + Functions ortak debugu icin daha sıkı araclar bekliyoruz. Hydrogen baglami icin Berlin Tech Startup Shopify Guidei okuyun.
• SHOP App entegrasyonu: Checkoutta calisan functionlar zamanla SHOP App cartini da etkileyebilir — cross-surface tutarlilik bir tema olacak.
• Daha iyi gozlemlenebilirlik araclari: Sadece CLI pipe yerine resmi connector uzerinden harici gozlemlenebilirlik entegrasyonu (Datadog Honeycomb).

Senior muhendisler icin SSS

2026da hala Scripts yazmali miyiz?

Hayir. Shopify Scripts Agustos 2025te tamamen kapatildi. Bugun hala productionda Scripts varsa migration gecikmis demektir. Taktiksel yol icin Functions Developer Guideina bakin.

Functionlar middlewareimizi degistirebilir mi?

Tamamen degil. Functionlar checkoutta veya cartta calismasi gereken logikin yerini alir. Backoffice logiki (ERPye order sync envanter zenginlestirme harici tax hesaplama) app backendde kalir. Pratik kural: senkron deterministik ve checkout ile ilgili her sey Functions hattirde async harici veri agirlikli her sey app backendde.

Functionlari CIda nasil test ederiz?

Shopify CLIda shopify app function run --input fixture.json var. Function basina 5-15 input fixture (edge case bos cart cok buyuk cart uluslararasi musteri) ve output JSONa karsi snapshot test bulunduran bir klasor oneririz. CI jobu her PRda calisir.

Function hosting ne kadar tutar?

Functionlar Shopify Plusa ayri fiyat olmadan dahildir. Lambdadaki gibi cagri basina fiyatlama yok. Bu onemli bir avantaj — ayda 50 milyon kere calisan bir function ek hicbir sey maliyet etmiyor.

Functionlar Plustaki 25 uygulama sinirina sayilir mi?

Functionlar app extensiondur. Bir uygulama birden fazla function ile gelebilir. Sinir app seviyesindedir function seviyesinde degil. On iki functionli bir uygulama tek uygulama olarak sayilir.

Ayni functionda Rust ve AssemblyScripti karistirabilir miyiz?

Tek bir function icinde: hayir. Function tek bir kaynak dilinden derlenmis bir Wasm modulu. Ama ayni uygulamada her biri farkli bir dilde birden fazla function olabilir. Ekiplerin performans kritik functionlari Rustta basit konfigurasyon functionlarini JSde yazdigini goruyoruz.

Functionlar Checkout UI Extensions ile nasil etkilesir?

Ayri primitiftirler. Functionlar cart verisini donusturur UI Extensions checkoutta UI render eder. Bir UI Extension cart attribute kurabilir bir Function bunu okuyabilir — ana iletisim yolu budur.

Admin APIda private app sunucusunun hala daha iyi oldugu durumlar var mi?

Evet uc tane: (1) logik harici sisteme canli API cagrisi gerektirdiginde (tax envanter currency hedge) (2) hesaplama 5 msden onemli olcude fazlasini gerektirdiginde (karmasik routing optimizasyonu) (3) operasyon senkron checkout ile ilgili olmadiginda (order sync notification yeniden indeksleme).

2026da Function repo layoutu tipik olarak nasil gorunur?

Monorepoda bir Shopify uygulamasi extensions/ klasorunde function basina shopify.extension.toml src/run.ts (veya src/main.rs) schema.graphql ve tests/fixtures/*.json iceren bir alt klasor. shopify app generate schema ile codegen. shopify app deploy ile deploy.

Productionda zaman zaman fail eden bir function nasil debug edilir?

Partners dashboardundaki Function Run loglama statu=failed ile filtreleme yapilmasini saglar. Ilgili input snapshotlari indirilebilir ve shopify app function run --input failed-run.json ile yerel olarak yeniden oynatilabilir. Repro icin en hizli yol.

Sonuc ve sonraki adimlar

Shopify Functions Scriptlerin sadece daha iyi versiyonu degil. Mimari bir yenilik — deterministik sinirli sandboxli edge co-lokalize ve dil bagimsiz. Bes milisaniye siniri sert ag yoklugu bir ozellik tercihi sinirlama degil. Bu kisitlari kabul eden Plus tacirleri indirim kargo odeme ve cart logikinin storefront CDN cache hitleri kadar hizli guvenli ve auditable calistigi bir platform katmani geri alirlar.

Burada anlattigimiz kaliplar — kademeli indirim yigma carrier farkindalikli teslimat compliance odakli odeme yonlendirme — gercek ve 2026da DACH ile uluslararasi Plus tacirleri tarafindan productionda calistiriliyor. Functionlarin yapamadigi (canli harici cagrilar UI degisiklikleri uzun hesaplamalar) komsu katmanlara aittir: UI icin Checkout UI Extensions harici entegrasyon icin Admin APIda app backend on hesaplama icin webhook sync.

Plus mimarinizi yeniden dusunuyorsaniz veya Scripts migrationiniz hala finalize degilse — mimari incelemelerinde function pattern workshoplarinda ve somut Plus migrationlarinda yardim ederiz. Iletisim uzerinden bizimle konusun veya Custom Development pratiginde ne kurduğumuzu okuyun. Hydrogeni Functionsla birlestirmek isteyen Berlinli ekipler icin Shopify Agentur Berlin sayfamiz iyi bir baslangic.

Ek okuma: taktiksel Functions Developer Guide Hydrogen baglamiyla Berlin Tech Startup Playbook ve Scriptsden veya baska platformlardan gecen magazalar icin Migration Services.

34Devs Korschenbroichta Duesseldorftan 20 dakika uzaklikta ve 2022den beri Shopify Plus mimari uzerinde calisiyor — ilk Functions MVPlerinden Hydrogen storefrontlari ile coklu function bestelenebilirligi setuplarina kadar. Mimari sorulari memnuniyetle kabul ederiz.