Shopify Functions Architektur: Das Wasm-at-Edge Modell, das viele Plus Merchants noch nicht verstanden haben

Vor zwei Wochen ist unser Migration-orientierter Functions-Post auf LinkedIn ueberraschend gut gelaufen. Ein Kommentar hat alles auf den Punkt gebracht: die Migration von Scripts zu Functions ist die offensichtliche Geschichte, aber die eigentliche Geschichte ist die Architektur. Shopify Functions ist nicht einfach ein Scripts-Ersatz mit anderer Syntax. Es ist eine voellig neue Laufzeit-Schicht in der Plattform — WebAssembly-Module, deterministisch ausgefuehrt, am Edge co-lokalisiert mit Checkout und Order Processing, mit harten Latenz-Budgets und Sandbox-Garantien, die Scripts nie hatte.

Dieser Artikel ist der architektonische Follow-up zu unserem Functions Developer Guide. Der vorherige Post war taktisch — wie migriere ich, was sind die API-Surfaces, wie sieht ein Discount aus. Dieser Post ist konzeptionell und richtet sich an Senior Engineers, CTOs und Engineering Manager bei Plus Stores, die wissen wollen, warum die Plattform so gebaut ist, wie die Runtime intern funktioniert und welche Design-Patterns das Modell ermoeglicht — und welche es bewusst ausschliesst.

Wir behandeln keine Buzzwords. Wir nennen ms-Zahlen, Memory-Limits und konkrete Tradeoffs. Wo das Modell schwach ist, sagen wir es. Wo Shopify einen besseren Tradeoff getroffen hat als die Konkurrenz, begruenden wir es technisch.

Das Runtime-Modell: Wasm-Sandbox mit harten Determinismus-Garantien

Shopify Functions sind WebAssembly-Module die in einer von Shopify kontrollierten Host-Umgebung ausgefuehrt werden. Vier harte technische Grenzen definieren die Runtime und alle vier sind bewusst gewaehlt.

• 5 MB Binary-Limit: Das deployed Wasm-Modul darf maximal 5 MB gross sein. In der Praxis kommt ein Rust-kompiliertes Discount-Module bei 80-400 KB raus, ein Javy-kompiliertes JS-Module bei 1.5-3 MB.
• 5 ms Execution-Budget pro Invocation: Harte Obergrenze. Mehr als 5 ms bedeutet, dass die Function abbricht und das System die Default-Logik anwendet (kein Discount, keine Anpassung). Typische produktive Functions laufen bei 0.8-2.5 ms.
• Fuel-basiertes Instruction Budget: Zusaetzlich zur Wall-Clock-Zeit verwendet Shopify ein Fuel-System (vergleichbar zu Wasmtime Fuel). Jeder Wasm-Befehl konsumiert Fuel. Eine Function die in einer Endlosschleife haengt verbrennt ihr Fuel-Kontingent und wird beendet — auch wenn die Wall-Clock-Zeit niedriger waere. Das schuetzt vor pathologischen Inputs.
• Kein I/O, keine Netzwerk-Calls, kein Shared State: Die Function hat keinen fetch, kein Filesystem, keinen Zugriff auf shared memory zwischen Invocations. Jeder Run startet mit leerer Memory, bekommt einen GraphQL-Input-Snapshot und produziert einen GraphQL-Output-Snapshot. Punkt.

Diese vier Grenzen sind keine Bugs. Sie sind die Sicherheits- und Latenzgarantie der Plattform. Wenn Shopify 250 Plus Merchants pro POP eine Function-Logik ausfuehren laesst und einer dieser Functions ein fetch mit drei Sekunden Timeout machen koennte, waere die Checkout-Latenz nicht mehr berechenbar. Indem Shopify alle Functions in eine deterministisch-bounded Wasm-Sandbox sperrt, kann die Plattform garantieren, dass kein Tenant einen anderen Tenant beeinflussen kann und dass jeder Checkout-Request ein berechenbares Worst-Case-Latency-Profil hat.

Host Functions und das Imports/Exports-Modell

Wer Wasm aus Cloudflare Workers oder Fastly Compute@Edge kennt, kennt das Konzept der Host Functions. Die Wasm-Sandbox selbst hat keine Faehigkeiten — sie kann rechnen, aber sie kann nichts beobachten. Die Host-Umgebung exportiert eine begrenzte Menge an Imports in die Sandbox, die die Function aufrufen kann. Shopify exportiert sehr wenig: im Wesentlichen shopify::function_input (gibt den GraphQL-Snapshot zurueck) und shopify::function_output (akzeptiert die Operations als Ergebnis). Es gibt keinen Host-Import fuer Netzwerk, kein http_get, kein storage_read. Das ist Absicht.

// Pseudocode: Host Function Interface (Shopify-internal)
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);
}

Was die Function im Wasm-Linear-Memory tut — Parsing, Iteration, Pattern Matching, Math — geht die Plattform nichts an. Was sie aus der Sandbox raus tut — nur Output schreiben und Logs senden — ist auf die zwei Host-Calls begrenzt.

Warum Wasm und nicht JavaScript-Isolates wie Cloudflare Workers?

Cloudflare Workers laufen in V8-Isolates. AWS Lambda laeuft in Container-VMs. Fastly Compute@Edge laeuft in Wasm via Lucet/Wasmtime. Shopify haette jede dieser Optionen waehlen koennen. Sie haben Wasm gewaehlt und die Entscheidung ist begruendet.

• Deterministisch by default: Wasm hat keine eingebauten Quellen von Non-Determinismus. Kein Math.random, kein Date.now (es sei denn explizit als Host-Import bereitgestellt), keine Filesystem-Zeit. Das macht Function-Runs reproduzierbar. Derselbe Input erzeugt denselben Output. Das ist fuer eine Plattform die fuer Compliance auditierbar sein muss von hohem Wert.
• Sandboxed by default: Wasm-Module koennen nur das tun, was die Host-Umgebung explizit erlaubt. V8-Isolates muessen das Sandboxing in der JS-API durchsetzen — was historisch immer wieder zu Side-Channel-Lecks gefuehrt hat (Spectre, Meltdown). Wasm ist auf Capability-Basis sicher.
• Sprachagnostisch: Rust, AssemblyScript, TinyGo, C, C++ und JS (via Javy) kompilieren zu Wasm. Shopify zwingt niemanden in JS — Teams mit Rust-DNA schreiben Rust-Functions, Teams die JS bevorzugen schreiben JS und kompilieren via Javy zu Wasm.
• Millisekunden-Cold-Start: Wasm-Module sind schneller zu instanziieren als V8-Isolates und drastisch schneller als Container. Shopify kann eine frisch geladene Function in unter 5 ms warmlaufen lassen — was bedeutet dass kein Pre-Warming-Aufwand wie bei Lambda noetig ist.
• Sicherheits-Isolation auf Plattform-Ebene: 250 Plus Merchants koennen ihre Functions auf demselben physischen Edge-Node ausfuehren ohne dass ein Tenant einen anderen sehen kann. Die Wasm-Linear-Memory ist pro Instance isoliert.

Der Tradeoff: Wasm ist schwerer zu debuggen als JS, weil Stack-Traces gegen die Wasm-Module-Symbole gelesen werden muessen und nicht gegen Source-Files. Shopify mildert das mit Source-Maps im Functions-CLI und mit den Function Run Logs im Partners Dashboard.

Edge-Execution-Topologie: Wo Functions tatsaechlich laufen

Functions laufen nicht in einem zentralen Rechenzentrum. Sie laufen in den Shopify Edge POPs — co-lokalisiert mit den Checkout- und Order-Processing-Services. Das bedeutet ein Cart-Update in Berlin trifft den Frankfurt-POP, dort laeuft die Cart-Transform-Function lokal mit unter 2 ms, und das Ergebnis wird direkt in den Checkout-State geschrieben. Kein Round-Trip nach Toronto. Keine Cross-Region-Latenz.

Fuer DACH-Merchants ist das relevant weil Frankfurt einer der groesseren EU-POPs ist und die Latenz zwischen einem Berliner Checkout-User und dem Functions-Run dort typischerweise 8-25 ms beim ersten Hop liegt. In der Praxis sehen wir bei Plus Stores die wir betreuen eine p50-Function-Latency von 1.4 ms und eine p99 von 3.8 ms.

Warum ist das fuer Checkout-Conversion relevant? Studien zeigen seit Jahren dass jede 100 ms zusaetzliche Checkout-Latenz die Conversion um etwa 0.5-1% druecken kann. Wenn die Discount- oder Delivery-Logik on Edge laeuft und nicht im App-Backend, sind das real eingesparte 200-600 ms pro Checkout-Page-Load.

Die Function API Surfaces in 2026 — Vollstaendige Uebersicht

Functions sind kein einzelner Endpoint. Es sind mehrere Target-APIs mit jeweils eigenem GraphQL-Input-Schema und Output-Operations-Set. Stand 2026 GA:

• product_discounts: Rabatte auf einzelne Produktvarianten. Ersetzt klassische Line-Item-Scripts. Ermoeglicht Pattern, die Scripts nie konnten — z.B. tag-basierte Tier-Logik mit Cart-Composition-Awareness.
• order_discounts: Rabatt auf den Bestellwert. Ersetzt Order-Scripts. Erlaubt komplexe Schwellen-Regeln (z.B. ueber alle Produkte einer Kategorie, mit Customer-Tag-Bedingungen).
• shipping_discounts: Rabatt auf Versandkosten. Free-Shipping-Thresholds, Customer-Tier-basierte Versandnachlaesse.
• delivery_customization: Liefer-Optionen filtern, umbenennen, neu sortieren. Beispiel: bei Bestellungen ueber 50 kg den Standard-Versand ausblenden und nur Spedition zeigen. Scripts hatten keinen vergleichbaren Hook.
• payment_customization: Payment-Methoden filtern, umbenennen, neu sortieren. Beispiel: bei B2B-Kunden Klarna ausblenden und Rechnung anzeigen. Bei Risiko-Tags PayPal entfernen.
• cart_transform: Bundle-Logik, Virtual Variants, Composite Products. Diese API ersetzt eine ganze Klasse von Apps die frueher mit Cart Attributes und Liquid-Hacks gebaut wurden.
• cart_checkout_validation: Validierungs-Regeln am Checkout. Beispiel: erlaubt nur EU-Lieferadressen, blockiert bestimmte Postleitzahlen. Fehler werden direkt am Checkout angezeigt.
• fulfillment_constraints: Steuert wie Bestellungen auf Locations aufgesplittet werden. Beispiel: alles aus einem Lager versenden wenn moeglich, sonst Multi-Location-Split mit definierter Prioritaet.
• order_routing: Welche Location bekommt welche Order-Line. Komplexere Logik als die alten Location-Priority-Settings.

Jede dieser APIs hat ihr eigenes GraphQL-Schema, eigene Input-Types und eigene Output-Operations. Codegen via Shopify CLI generiert die Rust- oder TypeScript-Types lokal aus dem Schema. Das macht die Function-Entwicklung typsicher.

Das Input-Output-Contract Modell: Snapshot rein, Operations raus

Das ist der konzeptionell wichtigste Punkt der ganzen Architektur. Functions arbeiten nicht auf Live-State. Sie bekommen einen Snapshot des Carts (oder der Order, je nach API), und sie geben Operations zurueck — kein neues Cart-Objekt, sondern eine Liste von Aenderungen.

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

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

Warum dieses Design? Weil es Race Conditions eliminiert. Scripts wurden synchron im Ruby-VM ausgefuehrt, aber sie konnten den Cart waehrend der Ausfuehrung modifizieren — was zu unklarem Verhalten bei mehreren Scripts fuehrte. Functions sehen einen eingefrorenen Snapshot, geben Operations zurueck, und Shopify wendet diese Operations in einer wohldefinierten Reihenfolge auf den Master-State an.

Das macht Functions auch nebenwirkungsfrei und damit cachebar. Bei identischem Input garantiert dasselbe Output. Das ist die Grundlage fuer die Function Replay Funktion im Partners Dashboard — Shopify kann jeden Function-Run mit dem urspruenglichen Input lokal nachstellen.

Komposition mehrerer Functions auf einem Store

Ein Plus-Store kann mehrere Functions gleichzeitig haben. Zwei Discount-Functions, eine Delivery-Customization, eine Payment-Customization, plus zwei Cart-Validation-Functions sind in produktiven Setups normal.

Wie wird die Reihenfolge festgelegt? Es gibt drei Ebenen.

• API-Reihenfolge: Die Plattform fuehrt erst cart_transform aus (das veraendert die Cart-Struktur), dann die Discount-APIs (product, order, shipping), dann delivery_customization und payment_customization, schliesslich cart_checkout_validation. Diese Reihenfolge ist deterministisch und dokumentiert.
• Innerhalb einer API: Discount Application Strategy (FIRST, MAXIMUM, ALL) steuert wie mehrere Discount-Functions kombiniert werden. FIRST nimmt den ersten matchenden Rabatt, MAXIMUM den hoechsten, ALL stapelt alle (mit Vorsicht).
• Pro Function: Innerhalb einer Function entscheidet der Code, ob er einen Operation zurueckgibt oder einen Leerwert. Eine Function die nichts zurueckgibt wirkt sich nicht aus.

In der Praxis sieht eine saubere Plus-Architektur 2026 so aus: eine Cart-Transform-Function fuer Bundles, zwei Product-Discount-Functions (eine fuer Loyalty-Tiers, eine fuer Promo-Codes), eine Order-Discount-Function fuer Spend-Thresholds, eine Delivery-Customization fuer Carrier-Logik, eine Payment-Customization fuer B2B-vs-DTC-Splits, und eine Validation-Function fuer Compliance-Regeln (z.B. nur EU-Lieferadressen).

State-Management ohne State: Die Standard-Patterns

Functions koennen keinen persistenten State zwischen Invocations halten. Wie schreiben Plus-Teams 2026 trotzdem komplexe Logik die auf Konfiguration und externe Daten zugreift?

• Metafields fuer Konfiguration: Tier-Schwellen, Discount-Prozentsaetze, Carrier-Rules, Excluded-Postleitzahlen kommen aus Shop-, Product-, oder Customer-Metafields. Diese werden im Function-Input mitgeliefert. Aenderungen am Metafield-Wert wirken sofort auf den naechsten Function-Run.
• App-Backend fuer externe Datenanreicherung via Webhooks: Wenn die Function einen Wert braucht der nicht in Shopify liegt — z.B. den aktuellen Lagerbestand eines externen ERP — synct ein App-Backend regelmaessig die externen Daten in Shopify-Metafields. Die Function liest dann nur das Metafield. Kein Live-API-Call notwendig.
• Cart Attributes fuer Function-zu-Function-Kommunikation: Eine cart_transform-Function kann ein Cart-Attribute setzen das eine spaetere discount-Function liest. Das ist der einzige Weg fuer Inter-Function-State-Sharing.
• customer.metafield fuer Personalisierung: Loyalty-Tier, Lifetime-Value, Bevorzugte-Kategorien werden als Customer-Metafields gespeichert und in der Function ausgelesen.
• Function-Settings UI ueber App Extensions: Eine Function kann mit einem Configuration UI im Shopify Admin geliefert werden. Settings werden als Metafield im Function-Owner-Namespace gespeichert.

Observability: Wie monitort man Functions in Production?

Functions kommen mit einer eingebauten Observability-Schicht die ueber das hinausgeht was Scripts hatten.

• Function Run Logs im Partners Dashboard: Jeder Function-Run loggt Input, Output, Wall-Clock-Zeit, Fuel-Verbrauch, und etwaige Logs aus dem shopify.functionLog-Call. Diese sind im Partners Dashboard pro Function durchsuchbar.
• shopify app function-runs CLI: Mit shopify app function-runs bekommt man die letzten Runs auf der Kommandozeile mit JSON-Output. Praktisch fuer Debugging und Snapshot-Replay.
• Replay-Funktion: Jeder Function-Run kann mit dem urspruenglichen Input lokal repliziert werden — shopify app function run --input run-2026-05-15.json. Das ist der mit Abstand wichtigste Debugging-Workflow.
• Performance-Budgets: Die p95-Latenz pro Function ist im Dashboard sichtbar. Wenn eine Function in Richtung 4 ms wandert ist das ein Warnsignal bevor sie das 5-ms-Limit reisst.
• Output-Validation: Wenn eine Function einen Output zurueckgibt der nicht zum GraphQL-Schema passt, schlaegt der Run fehl und wird geloggt. Das ist hilfreich gegen Type-Drift bei API-Updates.

// Beispiel function_log output
{
  "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"]
}

Wir empfehlen Plus-Teams in 2026, die shopify app function-runs-CLI-Outputs in eine externe Observability-Platform wie Datadog oder Honeycomb zu pipen. Das macht p99-Alerting und Cross-Service-Korrelation moeglich.

Sicherheits-Implikationen der Wasm-Sandbox

Wenn ein Plus-Merchant eine Function eines Drittanbieter-Apps installiert — z.B. einer Discount-Stacking-App von einem App-Store-Partner — bekommt der Drittanbieter Code-Ausfuehrungsrechte im Checkout-Flow. Bei Scripts war das ein realer Supply-Chain-Risikofaktor. Bei Functions ist das deutlich weniger problematisch, weil die Function in einer harten Sandbox laeuft.

• Kein Datenabfluss: Die Function kann keine Daten aus dem Cart an einen Drittserver senden. Sie hat kein Netzwerk. Selbst wenn der App-Entwickler boese Absichten haette, koennte er die Cart-Daten nicht exfiltrieren.
• Kein Lateral Movement: Die Function sieht nur den GraphQL-Input den die API erlaubt. Keinen Zugriff auf andere Customers, andere Orders, andere Shops auf demselben Edge-Node.
• Hard-Limits gegen Denial-of-Service: Eine Function die endlos schleift verbrennt ihr Fuel und wird beendet. Sie kann den Checkout nicht aufhaengen.
• Auditierbare Code-Basis: Function-Bundles sind im App-Store sichtbar und koennen vor Installation von einem Security-Reviewer angeschaut werden. Bei Scripts war das praktisch unmoeglich.

Fuer Plus-Compliance-Teams ist das ein echter Fortschritt. Wir sehen bei Enterprise-Plus-Kunden die wir beraten dass die Security-Sign-off-Zeit fuer eine Function-App von zwei Wochen (bei Scripts: vier bis sechs) gefallen ist.

Drei Architektur-Patterns die Plus-Merchants 2026 sauber umsetzen

Pattern A: Tiered Discount Stacking mit Cart-Snapshot-Awareness

Problem: Loyalty-Tier-Kunden bekommen 10% Rabatt auf Tier 1, 15% auf Tier 2, 20% auf Tier 3. Zusaetzlich gibt es einen Promo-Code von 5%. Die Regel: die hoechste der Tier- und Promo-Rabatte gilt, aber kombiniert mit Free Shipping ab 80 EUR Cart-Wert.

Naiv mit Scripts: ein Order-Script das alle Bedingungen in einem Block prueft. Bei drei Aenderungen pro Quartal wird das Script eine Schicht von Conditionals die niemand mehr versteht.

Functions-Architektur: drei separate Functions. Function 1 (product_discounts): wendet Tier-Rabatt auf alle Lines an, liest Tier aus customer.metafield. Function 2 (order_discounts): prueft Promo-Code aus Cart Attribute, vergleicht mit Tier-Discount, gibt die hoehere Variante zurueck via discountApplicationStrategy MAXIMUM. Function 3 (shipping_discounts): setzt Versand auf null bei Cart-Total ueber 80 EUR.

Warum besser: jede Function ist einzeln testbar, einzeln versionierbar, einzeln deploybar. Aenderung am Tier-Schwellenwert ist eine Metafield-Aenderung. Aenderung am Promo-Code-Verhalten ist ein Function-Deploy. Kein gemeinsamer Code-Pfad, keine Regression-Gefahr.

Pattern B: Carrier-Aware Delivery Rules fuer DACH-Logistik

Problem: DHL fuer Pakete unter 30 kg, DPD bei 30-150 kg, Spedition ab 150 kg, Express-Optionen nur in Deutschland und Oesterreich, kein Versand in die Schweiz fuer bestimmte Lithium-haltige Produkte.

Naiv mit Shipping-Profiles: drei Versandzonen mit drei Versandprofilen, die in Shopify-Shipping-Settings konfiguriert werden — das skaliert bis ungefaehr fuenf Produkt-Kategorien, danach wird die Konfiguration unwartbar.

Functions-Architektur: eine delivery_customization-Function. Input ist der Cart inkl. Variant-Metafields (Gewicht-Kategorie, Lithium-Flag). Function filtert die verfuegbaren Versandoptionen basierend auf Cart-Composition und Lieferland. Ergebnis: eine saubere Liste von erlaubten Carriern pro Cart.

Warum besser: die Logik ist in Code, nicht in einer UI. Code ist versionierbar, testbar, durch Code-Review absicherbar. Neue Regel (z.B. SwissPost-Ausschluss fuer Lithium) ist ein zwei-Zeilen-PR statt zehn-Klick-Konfiguration.

Pattern C: Compliance-driven Payment Routing fuer DACH

Problem: B2B-Firmenkunden sehen Rechnungskauf via Billie, B2C-Kunden Klarna, Schweizer Kunden TWINT, hohe Bestellwerte ab 1.500 EUR werden ohne Klarna gezeigt (Risiko-Compliance), Kunden mit risikobehaftetem customer.tag sehen kein Pay-Later.

Naiv mit Scripts: ein Payment-Script mit fuenf if-Bloecken. Wartbarkeit nach drei Quartalen: schlecht.

Functions-Architektur: eine payment_customization-Function. Liest customer.tags, customer.metafield (Risiko-Score vom App-Backend synct), cart.totalAmount, deliveryAddress.country. Reorder und Filter der Payment-Optionen sind eine reine Funktion ueber den Input. Tests sind unit-testable mit Snapshot-Files.

Vergleich zur Konkurrenz: BigCommerce, Salesforce Commerce Cloud, commercetools

Was machen andere Commerce-Plattformen in dieser Schicht?

• BigCommerce: bietet GraphQL Storefront API und Webhooks, aber keine vergleichbare Edge-Wasm-Schicht. Custom Discount Logic wird typischerweise im Frontend (Headless) oder im App-Backend implementiert. Schneller zu starten, aber Latenz und Sicherheits-Isolation sind nicht im selben Bereich.
• Salesforce Commerce Cloud: hat OCAPI-Hooks und SFRA, aber das laeuft im JVM-Container im Salesforce-Datacenter — Cold-Start-Latenzen sind hoeher, und die Sprache (SFCC ISML, JS) ist weniger flexibel als Wasm-mit-vielen-Sprachen.
• commercetools: bietet API Extensions und Subscriptions die externe Functions triggern — typischerweise als AWS Lambda. Das ist flexibler bezueglich Netzwerkzugriff, aber langsamer (Cold-Start 100-500 ms) und schwerer zu auditieren.
• Adobe Commerce: traditionelle PHP-Plugin-Welt, kein vergleichbares Sandbox-Modell.

Shopifys Tradeoff ist klar: hartes Limit (5 ms, kein Netzwerk) im Tausch fuer determinitisches, sicheres, billiges Edge-Execution. Wenn ein Merchant wirklich ein Live-API-Call braucht (z.B. externe Steuer-Berechnung), bleibt das App-Backend mit Admin API der richtige Layer. Functions sind nicht das letzte Wort fuer alles.

Was Functions in 2026 immer noch nicht koennen

Ehrliche Limitationen:

• Kein Netzwerk: Kein fetch, kein externer API-Call, keine Live-Daten aus einem PIM, ERP oder Steuer-Service. Wenn die Logik live externe Daten braucht, geht das ueber Webhook-getriebene Metafield-Syncs vom App-Backend.
• Keine Checkout-UI-Aenderung: Functions koennen Daten transformieren, aber nicht die Checkout-UI veraendern. Dafuer gibt es Checkout UI Extensions, ein eigenes Primitiv.
• 5-ms-Cap ist hart: Komplexe Algorithmen mit hundertfachen Cart-Iterationen oder grossen Datenstrukturen koennen das Budget sprengen. Wir empfehlen Profiling mit dem Function Runner vor dem Deploy.
• Keine Pricing-API-Berechnung in Echtzeit: Dynamic Pricing auf Basis externer Preis-Engines (z.B. Currency-Hedging-Service) geht nicht direkt — es muss als Metafield-Snapshot vorbereitet werden.
• Keine Async-Operations: Functions sind synchron, single-threaded, kein Promise.all, kein Worker-Pool.
• Begrenzte Input-Tiefe: Der GraphQL-Input ist auf eine bestimmte Tiefe und Anzahl von Lines beschraenkt. Sehr grosse B2B-Carts mit 500+ Lines koennen Edge-Cases triggern.

Wo Shopify hingeht: 2026 und darueber hinaus

Drei Trends die wir bei Shopifys Function-Roadmap sehen:

• Mehr API-Surfaces: fulfillment_constraints und order_routing reifen weiter, neue APIs fuer Subscription-Pricing und Bundle-Constraints sind in Discussion. Wir erwarten 2026/2027 noch 2-3 weitere Target-APIs.
• Konvergenz mit Hydrogen und OXP: Functions sind bereits in die Hydrogen-Storefront-Welt integriert (Discount-Logik aus Functions wird im Hydrogen-Cart respektiert). Wir erwarten engere Werkzeuge fuer das gemeinsame Debugging von Hydrogen + Functions. Siehe unseren Berlin Tech Startup Shopify Guide fuer den Hydrogen-Kontext.
• SHOP App Integration: Functions die im Checkout laufen, koennen perspektivisch auch im SHOP-App-Cart wirken — Cross-Surface-Konsistenz wird ein Theme.
• Bessere Observability-Tools: Externe Observability-Integration (Datadog, Honeycomb) ueber offizielle Connectors statt nur ueber CLI-Pipes.

FAQ fuer Senior Engineers

Sollten wir 2026 noch Scripts schreiben?

Nein. Shopify Scripts wurden im August 2025 endgueltig abgeschaltet. Wenn Sie heute noch Scripts in Produktion haben, ist die Migration ueberfaellig. Siehe unseren Functions Developer Guide fuer den taktischen Pfad.

Koennen Functions unsere Middleware ersetzen?

Nicht vollstaendig. Functions ersetzen die Logik die am Checkout oder am Cart ausgefuehrt werden muss. Backoffice-Logik (Order-Sync zu ERP, Inventar-Anreicherung, externes Tax-Calculation) bleibt im App-Backend. Faustregel: alles synchron-deterministisch-checkout-relevant gehoert in Functions, alles async-extern-daten gehoert in das App-Backend.

Wie testen wir Functions in CI?

Shopify CLI hat shopify app function run --input fixture.json. Wir empfehlen pro Function einen Ordner mit 5-15 Input-Fixtures (Edge-Cases, leerer Cart, sehr grosser Cart, internationale Kunden) und Snapshot-Tests gegen Output-JSON. CI-Job laeuft auf jedem PR.

Was kostet das Function-Hosting?

Functions sind in Shopify Plus ohne separates Pricing enthalten. Es gibt kein Per-Invocation-Pricing wie bei Lambda. Das ist ein erheblicher Vorteil — eine Function die 50 Millionen mal pro Monat laeuft kostet null Extras.

Zaehlen Functions zum 25-App-Limit auf Plus?

Functions sind App-Extensions. Eine App kann mehrere Functions ausliefern. Das Limit greift auf App-Ebene, nicht auf Function-Ebene. Eine App mit zwoelf Functions zaehlt als eine App.

Koennen wir Rust und AssemblyScript in derselben Function nutzen?

Innerhalb einer einzelnen Function: nein. Eine Function ist ein Wasm-Modul, das aus einer Sprache kompiliert wird. Aber Sie koennen mehrere Functions in derselben App haben, jede in einer anderen Sprache. Wir sehen Teams die Performance-kritische Functions in Rust schreiben und einfache Configuration-Functions in JS.

Wie interagieren Functions mit Checkout UI Extensions?

Sie sind getrennte Primitives. Functions transformieren Cart-Daten, UI Extensions zeigen UI im Checkout. Eine UI Extension kann Cart Attributes setzen, die eine Function lesen kann — das ist der Hauptkommunikationsweg.

Gibt es Faelle wo ein privater App-Server mit Admin API noch besser ist?

Ja, drei: (1) wenn die Logik einen Live-API-Call zu einem externen System braucht (Tax, Inventar, Currency-Hedge), (2) wenn die Berechnung deutlich mehr als 5 ms braucht (komplexe Routing-Optimierung), (3) wenn die Operation nicht-synchron-checkout-relevant ist (Order-Sync, Notification, Re-Indexing).

Wie sieht ein Function-Repo-Layout 2026 typischerweise aus?

Eine Shopify-App im Monorepo, im extensions/-Folder pro Function ein Unterordner mit shopify.extension.toml, src/run.ts (oder src/main.rs), schema.graphql, tests/fixtures/*.json. Codegen ueber shopify app generate schema. Deploy ueber shopify app deploy.

Wie debuggen wir eine Function die in Production sporadisch failt?

Function Runs Logging im Partners Dashboard erlaubt das Filtern nach Status=failed. Die zugehoerigen Input-Snapshots koennen heruntergeladen und mit shopify app function run --input failed-run.json lokal repliziert werden. Das ist der schnellste Pfad zum Repro.

Fazit und naechste Schritte

Shopify Functions ist nicht einfach eine bessere Version von Scripts. Es ist eine architektonische Neuerung, die deterministisch-bounded, sandboxed, edge-co-lokalisiert und sprachagnostisch ist. Die fuenf-Millisekunden-Grenze ist hart, das Fehlen von Netzwerk ist eine Featurewahl, nicht eine Limitierung. Plus-Merchants die diese Constraints akzeptieren bekommen eine Plattform-Schicht zurueck, in der Discount-, Versand-, Payment- und Cart-Logik so schnell, sicher und auditierbar laufen wie Storefront-CDN-Cache-Hits.

Die Patterns die wir hier beschrieben haben — Tiered Discount Stacking, Carrier-Aware Delivery, Compliance-Payment-Routing — sind real und werden in 2026 von Plus-Merchants in DACH und international produktiv betrieben. Was Functions nicht koennen (Live-Externe-Calls, UI-Aenderungen, lange Berechnungen), gehoert in benachbarte Layer: Checkout UI Extensions fuer UI, App-Backend mit Admin API fuer externe Integration, Webhook-Sync fuer Pre-Computation.

Wenn Sie Ihre Plus-Architektur gerade neu denken oder Ihre Scripts-Migration noch nicht final ist — wir helfen bei Architecture-Reviews, Function-Patterns-Workshops und konkreten Plus-Migrationen. Sprechen Sie mit uns ueber Kontakt oder lesen Sie was wir in der Custom Development Praxis bauen. Fuer Berliner Teams die Hydrogen plus Functions kombinieren wollen ist unsere Shopify Agentur Berlin Seite ein guter Startpunkt.

Weiterfuehrendes Material: der taktische Functions Developer Guide, der Berlin Tech Startup Playbook mit Hydrogen-Kontext und unsere Migration Services fuer Stores die aus Scripts oder anderen Plattformen kommen.

34Devs sitzt in Korschenbroich, 20 Minuten von Duesseldorf, und arbeitet seit 2022 an Shopify-Plus-Architekturen — von ersten Functions-MVPs bis zu Multi-Function-Composability-Setups mit Hydrogen-Storefronts. Fragen zur Architektur sind willkommen.