Dein Shopify-Plus-Storefront startet mit einem Lighthouse-Score von 98. Der Launch fühlte sich perfekt an – Hydrogens Streaming-SSR, Sub-900ms-LCP, null Layout-Shift. Nach drei Monaten sinkt die Checkout-Conversion um 14%. Dein Product-Team beschuldigt die Cart-API. Engineering zeigt auf Third-Party-Scripts. Finance hinterfragt die sechsstellige Replatform. Ich habe diese exakte Sequenz in 87 der 400+ headless Shopify Builds gesehen, die wir seit 2020 auditiert haben. Der Unterschied zwischen Storefronts, die innerhalb von vier Monaten $1M ARR erreichen, und denen, die zwei Quartale lang stagnieren, liegt nicht bei Hydrogen versus Next.js – sondern bei drei Migrationsentscheidungen, die die meisten Teams vor dem ersten Commit falsch treffen. Hier ist, was 400 Builds uns über die Fallen gelehrt haben, die keine Framework-Dokumentation erwähnt.

Dieser Guide enthält alles, das ich mir 2020 hätte wünschen sollen, als ich meinen ersten headless Shopify Store mit einem zusammengesetzten Next.js-Setup und der alten REST-API gebaut habe. Es ist das destillierte Wissen aus dem Bau von Storefronts für DTC-Marken, B2B-Großhändler und Enterprise-Shopify-Plus-Merchants. Manches wird Ihre Vermutungen bestätigen. Manches wird die konventionelle Weisheit herausfordern, die Sie auf Twitter lesen.

Lassen Sie uns einsteigen.

Inhaltsverzeichnis

Headless Shopify Development Guide 2026: Hydrogen, Next.js & Beyond

Was Headless Shopify 2026 wirklich bedeutet

Headless Shopify bedeutet, die Frontend-Präsentationsschicht vom Backend von Shopify zu entkoppeln. Du behältst Shopify für das, wofür es wirklich großartig ist – Inventar, Bestellungen, Zahlungen, Fulfillment – und ersetzt Liquid-Themes mit einem benutzerdefinierten Frontend, das mit der Storefront API kommuniziert.

Aber hier ist das, was die meisten Artikel nicht sagen werden: Headless Shopify 2026 ist ein völlig anderes Tier als noch vor zwei Jahren. Drei Verschiebungen haben die Landschaft grundlegend verändert:

  1. Hydrogen 2 ist ausgereift. Shopifys React-basiertes Framework, das auf Oxygen (ihrer Hosting-Plattform) läuft, hat sich seit dem turbulenten Start 2023 erheblich stabilisiert. Es läuft jetzt unter der Haube auf Remix und wird mit vernünftigen Defaults ausgeliefert.

  2. Die Storefront API erreichte Version 2025-04. Dies brachte Customer Account API v2, Verbesserungen der prädiktiven Suche und – entscheidend – serverseitige Cart-Operationen, die kein client-seitiges JavaScript erfordern.

  3. Checkout Extensions ersetzten checkout.liquid vollständig. Ab August 2025 müssen alle Shopify-Plus-Stores Checkout Extensibility nutzen. Keine Liquid-Checkout-Anpassung mehr. Allein dies trieb Tausende von Stores zu Headless-Architekturen.

Das mentale Modell, das ich nutze: Shopify ist deine Commerce-Engine. Dein Frontend ist eine Schnittstelle, die Daten aus dieser Engine abruft. Alles dazwischen sind API-Aufrufe und Caching-Strategie.

Der Architektur-Stack

Ein typisches Headless-Shopify-Setup 2026 sieht so aus:

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│   Frontend App   │────▶│  Storefront API   │────▶│  Shopify Backend │
│  (Hydrogen/Next) │     │  (GraphQL)        │     │  (Admin, Orders) │
└─────────────────┘     └──────────────────┘     └─────────────────┘
        │                                                  │
        ▼                                                  ▼
┌─────────────────┐                              ┌─────────────────┐
│   Headless CMS   │                              │  Checkout Ext.  │
│  (Sanity/Contentful)                            │  (Shopify UI Ext)│
└─────────────────┘                              └─────────────────┘

Das Frontend kommuniziert über GraphQL mit der Storefront API. Content, der nicht zu Shopify gehört (Editorial-Seiten, Landing Pages, komplexe Content-Modelle), lebt in einem Headless CMS. Checkout-Anpassungen erfolgen über Shopifys Erweiterungspunkte, nicht über benutzerdefiniertes Markup.

Die Storefront API: Dein neuer bester Freund

Die Storefront API ist eine öffentlich verfügbare GraphQL API, die speziell für kundenorientierte Erfahrungen entwickelt wurde. Sie unterscheidet sich von der Admin API, die Backend-Operationen verwaltet. Diese Unterscheidung zu verstehen ist entscheidend.

Was du tun kannst

query ProductPage($handle: String!) {
  product(handle: $handle) {
    id
    title
    description
    priceRange {
      minVariantPrice {
        amount
        currencyCode
      }
    }
    variants(first: 100) {
      edges {
        node {
          id
          title
          availableForSale
          selectedOptions {
            name
            value
          }
          price {
            amount
            currencyCode
          }
        }
      }
    }
    metafields(identifiers: [
      { namespace: "custom", key: "sizing_guide" },
      { namespace: "custom", key: "material_info" }
    ]) {
      key
      value
      type
    }
    media(first: 20) {
      edges {
        node {
          ... on MediaImage {
            image {
              url
              altText
              width
              height
            }
          }
          ... on Video {
            sources {
              url
              mimeType
            }
          }
        }
      }
    }
  }
}

Rate Limits und Caching

Ab 2026 erlaubt die Storefront API 100 Anfragen pro Sekunde pro Store für öffentliche Access-Token (erhöht von 60 in früh 2024). Private Access-Tokens erhalten höhere Limits. Aber du solltest diese Limits ohnehin nicht erreichen – wenn doch, ist deine Caching-Strategie fehlerhaft.

Hier ist, was ich bei jedem Projekt mache:

  • Full-Page-Caching auf CDN-Ebene (Vercel, Cloudflare oder Oxygen) mit stale-while-revalidate-Headern
  • Data-Layer-Caching mit 60-Sekunden-TTLs für Produktdaten, 300 Sekunden für Collectiondaten
  • Cart-Operationen werden niemals gecacht – diese treffen die API direkt jedes Mal
  • Bestandsprüfungen verwenden einen leichten Polling-Mechanismus oder Webhooks, um veraltete Bestandsdaten zu invalidieren
// Beispiel: Caching-Strategie für Produktabfragen in Next.js
export async function getProduct(handle: string) {
  const data = await shopifyFetch({
    query: PRODUCT_QUERY,
    variables: { handle },
    cache: 'force-cache',
    next: { revalidate: 60, tags: [`product-${handle}`] },
  });
  return data.product;
}

Hydrogen vs Next.js Commerce: Der echte Vergleich

Das ist die Frage, die mir am häufigsten gestellt wird. Und die ehrliche Antwort ist: Es hängt von deinem Team, deinem Zeitrahmen und deinen Hosting-Präferenzen ab. Aber hier sind die Daten.

Faktor Hydrogen 2 (Remix/Oxygen) Next.js Commerce (Vercel)
Framework Remix (React) Next.js 15 (React)
Hosting Oxygen (Shopify) oder Self-Host Vercel, Netlify, Self-Host
Shopify-Integration First-Party, tief Community-gepflegt
Lernkurve Moderat (Remix-Muster) Niedriger (wenn Team Next.js kennt)
CMS-Flexibilität Gut, aber Shopify-zentriert Ausgezeichnet – Ökosystem ist riesig
Mittleres LCP (unsere Daten) 0,8s 0,7s
Mittleres TTFB 120ms (Oxygen) 90ms (Vercel Edge)
Kosten im Maßstab Oxygen Free Tier großzügig Vercel Pro $20/Mo, Enterprise $$$
Checkout-Integration Nativer Cart → Checkout-Flow Erfordert Storefront-API-Cart-Setup
Ökosystem-Plugins Wachsend, ~200 Pakete Riesig, 10k+ Pakete
Community-Größe ~15k GitHub Stars ~40k GitHub Stars

Wann Hydrogen wählen

Wähle Hydrogen, wenn:

  • Dein Team sich mit Remix-Loader-/Action-Mustern wohlfühlt
  • Du die nächste Native-Shopify-Erfahrung möchtest
  • Du ein Shopify-Plus-Merchant bist, der Oxygen-Hosting möchte
  • Du keine schwere Non-Commerce-Content-Anforderungen hast (Blog, Editorial, etc.)

Wann Next.js wählen

Wähle Next.js, wenn:

  • Dein Team bereits Next.js-Apps ausliefert
  • Du tiefe CMS-Integration jenseits von Shopifys Metafields brauchst
  • Du maximale Hosting-Flexibilität möchtest
  • Du eine Content-schwere Brand-Erfahrung neben Commerce baust
  • Du potenziell in der Zukunft Commerce-Backends wechseln planst

Ich werde direkt: Bei 70% der Stores, die ich im letzten Jahr gebaut habe, war Next.js der richtige Call. Nicht weil es technisch überlegen ist – das ist es nicht unbedingt – sondern weil der Talent-Pool 5x größer ist und das Ökosystem mehr Lösungen für Edge Cases hat. Wenn das Marketing-Team deines Clients eine bestimmte Animation-Library möchte oder deine SEO-Agentur eine bestimmte Meta-Tag-Struktur erfordert, findest du die Antwort schneller in der Next.js-Welt.

Trotzdem haben Hydrogen-Stores auf Oxygen eine Deployment-Einfachheit, die schwer zu schlagen ist. Push zum Main, es ist live. Keine Build-Konfiguration, keine Cold-Starts bei Edge-Funktionen zum Debuggen.

Headless Shopify Development Guide 2026: Hydrogen, Next.js & Beyond - architecture

Sub-1-Sekunden-LCP erreichen

Hier trennt sich die Spreu vom Weizen. Der gesamte Business Case für Headless Shopify – die tatsächliche finanzielle Begründung – ruht auf Performance. Und die Zahl, die du erreichen musst, ist Sub-1-Sekunden Largest Contentful Paint auf Mobile.

Hier ist warum: Jede 100ms LCP-Verbesserung korreliert mit ungefähr einer 1% Steigerung der Conversion Rate, laut Shopifys eigenem Performance-Bericht von 2025. Ein Store, der $5M/Jahr macht und von 2,5s LCP (typisches Liquid Theme) zu 0,9s LCP geht, kann mit ungefähr einem 15% Anstieg rechnen. Das sind $750K zusätzliche Einnahmen.

Unsere Daten über 400+ Sites bestätigen diesen Bereich. Headless Storefronts sind 60-75% schneller als Liquid Themes im Durchschnitt, gemessen durch echte Benutzer Core Web Vitals Daten in CrUX-Berichten.

Das Performance-Playbook

Hier ist genau, wie wir konsistent Sub-1-Sekunden-LCP erreichen:

1. Server-render den kritischen Pfad

// Next.js App Router – Server-Komponente für Produktseite
export default async function ProductPage({ params }: { params: { handle: string } }) {
  const product = await getProduct(params.handle);
  
  return (
    <main>
      <ProductHero product={product} />
      <Suspense fallback={<PriceSkeleton />}>
        <ProductPricing productId={product.id} />
      </Suspense>
      <Suspense fallback={<ReviewsSkeleton />}>
        <ProductReviews productId={product.id} />
      </Suspense>
    </main>
  );
}

2. Optimiere Bilder aggressiv

Shopifys CDN unterstützt width-, height- und crop-Parameter. Nutze sie. Diene kein 2000px Hero-Image an einen 375px Mobile-Viewport.

function getOptimizedImageUrl(url: string, width: number) {
  const imageUrl = new URL(url);
  imageUrl.searchParams.set('width', String(width));
  imageUrl.searchParams.set('format', 'webp');
  return imageUrl.toString();
}

3. Preload das LCP-Image

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

4. Inline kritisches CSS, verschiebe alles andere

Wir halten Above-the-Fold-CSS unter 14KB (eine TCP-Runde). Alles andere lädt asynchron.

5. Edge-Side-Rendering

Sowohl Vercel Edge Functions als auch Oxygens Worker-Laufzeit führen an der Edge aus, was dir global sub-100ms TTFB gibt. Das ist der einzelne größte Performance-Hebel, den du ziehen kannst.

6. Prefetch bei Intent

Prefetch nicht alles auf Viewport. Prefetch auf Hover/Touch-Start. Das reduziert unnötige Bandbreite um ~40%, während es sich immer noch instant anfühlt.

Checkout Extensions und die Post-Checkout.liquid-Ära

Hier ist die Änderung, die vielen Merchants die Hände zwang: Ab August 2025 setzte Shopify checkout.liquid auf Plus Stores außer Kraft. Wenn du custom Checkout-Modifikationen hattest – und die meisten Plus Merchants hatten es – musstest du zu Checkout Extensions migrieren.

Checkout Extensions verwenden Shopifys UI Extensions Framework. Du schreibst React-ähnliche Komponenten, die sich in Shopifys Checkout innerhalb definierter Erweiterungspunkte rendern (Pre-Purchase, Post-Purchase, Shipping, Payment, etc.).

// Beispiel: Post-Purchase-Upsell-Extension
import { useApi, reactExtension, BlockStack, Text, Button } from '@shopify/ui-extensions-react/checkout';

export default reactExtension('purchase.checkout.block.render', () => <UpsellBlock />);

function UpsellBlock() {
  const { cost, lines } = useApi();
  
  return (
    <BlockStack>
      <Text size="medium">Passende Accessoires hinzufügen?</Text>
      <Button onPress={() => { /* add to cart logic */ }}>
        Hinzufügen für $19,99
      </Button>
    </BlockStack>
  );
}

Das Wichtigste zu verstehen: Checkout Extensions funktionieren gleich, ob du Headless bist oder ein Liquid Theme nutzt. Dein Headless Frontend übergibt an Shopifys Checkout, und die Extensions laufen dort. Das ist eigentlich ein großer Vorteil des Headless-Ansatzes – dein Storefront ist vollständig custom, aber Checkout bleibt von Shopify gehostet (PCI-konform, von Shopify gepflegt, etc.).

Shopify-Plus-Migrationsstrategie

Die Migration eines bestehenden Shopify-Plus Stores zu Headless ist eine phasierte Operation. Versuche nicht, alles auf einmal zu machen. Hier ist der Ansatz, der sich über unsere Projekte am besten bewährt hat:

Phase 1: Grundlagen (Wochen 1-3)

  • Richte das Frontend-Framework ein (Next.js oder Hydrogen)
  • Implementiere die Storefront-API-Verbindungsschicht mit Caching
  • Baue das Design-System / die Komponenten-Bibliothek
  • Richte CI/CD-Pipeline ein

Phase 2: Core Commerce (Wochen 4-8)

  • Produktlistungsseiten (Collections)
  • Produktdetailseiten
  • Cart-Funktionalität
  • Suche (nutze Shopifys Predictive Search API oder einen Drittanbieter wie Algolia)
  • Kontoseiten über Customer Account API

Phase 3: Content & Marketing (Wochen 9-11)

  • CMS-Integration für Non-Commerce-Seiten
  • Blog / Editorial-Sektion
  • Landing-Page-Builder für Marketing-Team
  • SEO-Migration (301 Redirects, Sitemap, Structured Data)

Phase 4: Launch & Optimierung (Wochen 12-14)

  • Performance-Audit und -Optimierung
  • A/B-Test-Setup
  • Analytics-Migration (GA4, Server-seitiges Tracking)
  • Schrittweise Traffic-Migration via Feature Flags oder Split Testing

Gesamtzeitrahmen: 12-14 Wochen für einen typischen Shopify-Plus-Store. Enterprise Stores mit komplexen Katalogen (50k+ SKUs) oder schwerer Anpassung können 16-20 Wochen dauern.

Die $1M-ARR-Schwelle: Wann Headless finanziell sinnvoll ist

Headless ist nicht kostenlos. Custom Frontend-Entwicklung kostet mehr als das Installieren eines Liquid Themes. Laufende Wartung erfordert Entwicklerzeit. Also wann rechnet sich die Mathematik?

Basierend auf unseren Daten: $1M ARR ist die Schwelle, bei der Headless Shopify beginnt, klaren finanziellen Sinn zu machen.

Hier ist die Mathematik:

Umsatzstufe Geschätzte Conv.-Raten-Steigerung Umsatzgewinn Headless-Build-Kosten Laufende jährliche Kosten ROI-Zeitrahmen
$500K ARR 10-15% $50-75K $80-150K $24-48K 18-24 Monate
$1M ARR 10-15% $100-150K $80-150K $24-48K 8-14 Monate
$3M ARR 10-15% $300-450K $120-200K $36-60K 4-6 Monate
$10M ARR 10-15% $1-1,5M $150-300K $48-96K 2-3 Monate

Unter $1M bist du besser dran, wenn du in Conversion Rate Optimization auf einem gut gebauten Liquid Theme investierst. Über $1M rechnen sich die Performance-Gewinne schnell genug, um die Investition zu rechtfertigen. Über $3M ist es nicht, zu Headless zu gehen, ernsthaft Geld liegen zu lassen.

Für spezifische Pricing-Informationen zu Headless-Builds, siehe unsere Pricing-Seite – wir sind transparent über Projektbereiche.

Agenturauswahl: Naturaily, Aalpha und darüber hinaus

Wenn du Agenturen für Headless-Shopify-Arbeit evaluierst, hier ist meine ehrliche Bewertung der Landschaft 2026.

Naturaily ist eine in Polen ansässige Agentur, die sich einen soliden Ruf für Headless Commerce aufgebaut hat, besonders mit Next.js und Vue Storefront. Ihre Stärken liegen im Mid-Market – Marken, die $1-10M machen und einen professionellen Build ohne Enterprise-Preisgestaltung brauchen. Sie sind technisch kompetent und haben gute Shopify Storefront API Erfahrung. Wo sie manchmal Schwierigkeiten haben: Hochgradig benutzerdefinierte B2B-Workflows und Multi-Market-Shopify-Setups.

Aalpha ist ein in Indien ansässiges Entwicklungsunternehmen mit breiterem Fokus – sie machen Mobile Apps, Enterprise-Software und Headless Commerce. Ihre Tarife sind deutlich niedriger (oft 40-60% weniger als westliche Agenturen), was sie für Budget-bewusste Projekte attraktiv macht. Der Trade-off liegt typischerweise im Projektmanagement-Overhead und Design-Polierung. Wenn du ein starkes internes Design-Team hast und das Projekt eng verwalten kannst, können sie solide technische Arbeit liefern.

Wie wir bei Social Animal vergleichen: Wir spezialisieren uns ausschließlich auf Headless-Webentwicklung – nicht nur Shopify, sondern das vollständige Spektrum der Headless-CMS und Framework-Arbeit einschließlich Next.js und Astro. Unser Sweet Spot sind Marken und Unternehmen, die tiefe technische Expertise ohne den Overhead einer großen Agentur brauchen. Wenn du neugierig auf Fit bist, kontaktiere uns – wir werden dir ehrlich sagen, ob wir die richtige Werkstatt für dein Projekt sind.

Faktor Social Animal Naturaily Aalpha
Spezialisierung Headless Web (tief) Headless Commerce + Web Full-Service Dev
Primäre Frameworks Next.js, Astro, Hydrogen Next.js, Vue Storefront Next.js, React Native
Team-Standort USA Polen Indien
Typischer Projektbereich $80-250K $60-200K $25-100K
Shopify-Plus-Erfahrung Ja (400+ Headless Sites) Ja Ja
Am besten für Performance-kritische Storefronts Mid-Market Headless Commerce Budget-bewusste Builds

Custom Storefronts mit Astro und anderen Frameworks

Hier ist etwas, das die meisten Shopify Headless Guides nicht sagen werden: Du musst nicht React verwenden.

Wir haben mehrere Shopify Storefronts mit Astro gebaut – besonders für Marken, wo Content und Editorial genauso wichtig sind wie Commerce. Astros Island-Architektur bedeutet, du schiffst standardmäßig null JavaScript und hydrisiert nur die interaktiven Bits (Cart, Produktwähler, Suche).

Die Ergebnisse? LCP konsistent unter 0,6 Sekunden. Gesamtseiten-Gewicht unter 100KB. Es ist absurd schnell.

---
// Astro-Komponente für eine Shopify-Produktkarte
import { getProduct } from '../lib/shopify';

const product = await getProduct(Astro.params.handle);
---

<article class="product-card">
  <img 
    src={product.featuredImage.url + '&width=600'}
    alt={product.featuredImage.altText}
    width="600"
    height="600"
    loading="lazy"
  />
  <h2>{product.title}</h2>
  <p class="price">${product.priceRange.minVariantPrice.amount}</p>
  
  <!-- Nur diese Komponente schifft JavaScript -->
  <AddToCart client:visible productId={product.id} />
</article>

Der Trade-off: Astros Ökosystem für Commerce ist kleiner. Du wirst mehr Custom Code für Cart-Management, Authentifizierung und Suche schreiben. Aber wenn Performance deine primäre Metrik ist und dein Team sich mit der zusätzlichen Arbeit wohlfühlt, ist es eine legitime Wahl.

FAQ

Ist Headless Shopify für kleine Stores lohnenswert?

Für Stores unter $500K ARR gewöhnlich nicht. Die Entwicklungs- und Wartungskosten überwiegen die Conversion-Rate-Verbesserungen. Du bist besser dran mit einem schnellen, gut optimierten Liquid Theme wie Dawn. Wenn du die $1M ARR Grenze überschreitest, verschieben sich die Economics entscheidend zugunsten von Headless.

Wie viel kostet ein Headless-Shopify-Build 2026?

Erwarte $80K-$300K für den initialen Build abhängig von Komplexität, Agentur-Standort und Feature-Umfang. Laufende Wartung kostet $2K-$8K pro Monat. Budget-Agenturen in Südasien können für $25K-$80K liefern, aber du wirst normalerweise stärkeres internes Projektmanagement und Quality Assurance brauchen.

Kann ich Shopifys Checkout mit einem Headless Storefront nutzen?

Ja, und du solltest. Shopifys Checkout ist PCI-konform, battle-tested und verwaltet die Zahlungsabwicklung. Dein Headless Frontend erstellt einen Cart über die Storefront API, dann leitet zu Shopifys gehosstetem Checkout weiter. Checkout Extensions lassen dich die Erfahrung innerhalb von Shopifys Erweiterungspunkten anpassen.

Was ist der Performance-Unterschied zwischen Headless und Liquid Themes?

Unsere Daten über 400+ Sites zeigen, dass Headless Storefronts 60-75% schneller sind als Liquid Themes bei Core Web Vitals Metriken. Speziell sinkt das mittlere LCP von 2,3-3,5 Sekunden (Liquid) auf 0,7-1,0 Sekunden (Headless). Das übersetzt sich in eine 10-15% Conversion-Rate-Verbesserung im Durchschnitt.

Sollte ich Hydrogen oder Next.js für meinen Headless-Shopify-Store nutzen?

Wenn dein Team Next.js kennt, nutze Next.js. Wenn du neu anfängst und die am meisten integrierte Shopify-Erfahrung mit minimaler Konfiguration möchtest, ist Hydrogen auf Oxygen ausgezeichnet. Der Performance-Unterschied zwischen ihnen ist vernachlässigbar – Team-Expertise und Ökosystem-Anforderungen sollten deine Entscheidung treiben.

Brauche ich Shopify Plus für Headless?

Technisch nein. Die Storefront API ist bei allen Shopify-Plänen verfügbar. Aber in der Praxis profitieren die meisten Headless Builds von Plus-Features: Checkout Extensions, Scripts, die Organization API für Multi-Store-Setups und höhere API-Rate-Limits. Bei der Umsatzstufe, wo Headless Sinn macht ($1M+), solltest du ohnehin auf Plus sein.

Wie lange dauert eine Headless-Shopify-Migration?

Eine typische Shopify-Plus-zu-Headless-Migration dauert 12-14 Wochen mit einem erfahrenen Team. Enterprise Stores mit komplexen Katalogen, schwerer Anpassung oder Multi-Market-Setups können 16-20 Wochen dauern. Lass dir nicht von jemandem sagen, dass es ein 4-Wochen-Job ist – so endet es mit einem kaputten Launch.

Was passiert mit meinen Shopify-Apps, wenn ich zu Headless gehe?

Das ist einer der größten Schmerzpunkte. Viele Shopify Apps injizieren Scripts in Liquid Themes, die nicht auf einem Headless Frontend funktionieren. Du musst jede App evaluieren: Manche bieten APIs, die du direkt integrieren kannst, manche haben Headless-kompatible Versionen, und manche müssen mit Custom Code oder Alternativen ersetzt werden. Plane App-Audit und Migration als Teil deines Projektumfangs.

Kann ich Astro oder andere Non-React-Frameworks mit Shopifys Storefront API nutzen?

Absolutely. Die Storefront API ist eine Standard-GraphQL-API – jedes Framework, das HTTP-Anfragen machen kann, kann sie nutzen. Wir haben Shopify Storefronts mit Astro, SvelteKit und sogar Vanilla JavaScript gebaut. Der Trade-off ist, dass Shopifys offizielles Tooling (Hydrogen, Cart-Utilities, etc.) React-basiert ist, also wirst du mehr Custom-Integrationscode mit anderen Frameworks schreiben.