Im Headless Commerce-Ökosystem ist Shopify die Produktdatenbank (PIM). Es zeichnet sich durch die Verwaltung von SKUs, Preisen und Lagerbeständen aus. Es ist wohl das schlechteste Content Management System (CMS) der Welt. Die „Online Store 2.0“-JSON-Vorlagen von Shopify sind starr. Metafelder sind im Wesentlichen untypisierte Zeichenfolgen. Um ein wirklich dynamisches, luxuriöses Schaufenster aufzubauen, benötigen Sie einen speziellen Content Lake.

Bei Maison Code Paris haben wir jedes Headless CMS (Contentful, Strapi, Prismic) bewertet. Wir haben uns für Sanity.io entschieden. In diesem Artikel werden die technischen Überlegungen, die Architektur und die Implementierungsdetails erläutert, die es uns ermöglichen, „Seitenersteller“ zu erstellen, die den Code nicht beschädigen.

Warum Maison Code darüber spricht

Bei Maison Code Paris fungieren wir als das architektonische Gewissen unserer Kunden. Wir übernehmen oft „moderne“ Stacks, die ohne grundlegendes Verständnis für Skalierung gebaut wurden.

Wir diskutieren dieses Thema, weil es einen kritischen Wendepunkt in der technischen Reife darstellt. Die korrekte Implementierung unterscheidet ein fragiles MVP von einer widerstandsfähigen Plattform auf Unternehmensniveau.

Die Philosophie: Inhalte als Daten, nicht als HTML

In WordPress oder einfachen CMS schreibt der Redakteur „Seiten“. Sie verfügen über einen WYSIWYG-Editor, mit dem sie Text fett formatieren, Bilder hinzufügen und im Wesentlichen HTML-Blobs schreiben können. Dies ist präsentationsgekoppelt. Wenn Sie diesen Inhalt in einer iOS-App oder einer WatchOS-Benachrichtigung wiederverwenden möchten, müssen Sie HTML-Strings analysieren.

Sanity behandelt Inhalte als strukturierte Daten. Ein „Heldenabschnitt“ ist kein „

“. Es ist ein JSON-Objekt: „json { „_type“: „Held“, „Überschrift“: „Sommerkollektion“, „cta“: { „label“: „Jetzt einkaufen“, „link“: „/collections/summer“ }, „Thema“: „dunkel“ } „ Das Frontend (React) entscheidet, wie dies gerendert wird. Der Herausgeber gibt lediglich die Absicht ein.

Die Abfrageebene: GROQ vs. GraphQL

Die meisten Headless-CMS bieten eine GraphQL-API. Es ist gut. Sanity bietet GROQ (Graph-Relational Object Queries). Es ist außergewöhnlich. Warum? Weil GROQ Projektionen (clientseitige Umformung auf dem Server) ermöglicht.

Szenario: Sie haben ein Autorendokument, auf das in einem Beitrag verwiesen wird. In GraphQL bestimmt das Schema die Form. In GROQ können Sie es im Handumdrehen umgestalten:

„Javascript // Alle Beiträge abrufen, aber „author.name“ in „scribedBy“ umbenennen *[_type == “post”] { Titel, „geschriebenVon“: Autor->Name, „estimatedReadingTime“: rund(Länge(Körper) / 5/60) + „min“ } „ Beachten Sie die Mathematik („rund“). Beachten Sie die Dereferenzierung des Zeigers („->“). Wir können die „Lesezeit“ auf der Datenbankebene berechnen. Wir können Datensätze verbinden. Wir können riesige Objekte in dünne DTOs (Data Transfer Objects) projizieren, die perfekt auf unsere React-Komponenten zugeschnitten sind.

Dies reduziert die Nutzlastgröße um 40–70 % im Vergleich zu Standard-GraphQL-Abfragen, die zu viel abrufen.

Architektur: Der Content Lake

Sanity ist ein Echtzeit-Dokumentenspeicher (gehostet in Google Cloud). Wenn „Alex“ im Studio ein Zeichen eingibt, wird es in Millisekunden über WebSocket mit dem Datenspeicher synchronisiert. „Chloe“ sieht, wie sich der Cursor sofort bewegt (Google Docs-Stil).

Dies löst die größte Reibung in Headless: Vorschau. Traditionelles Headless erfordert einen „Build“ (Next.js SSG), um Änderungen zu sehen. Das dauert 2 Minuten. Redakteure hassen es. Mit Sanity + Hydrogen (Remix) abonnieren wir den Content-Stream. Die Vorschau erfolgt sofort.

Der Reaktionshaken

„tsx import { useQuery } from ‘@sanity/react-loader’;

Exportfunktion useSanityQuery(query, params) { // Wenn innerhalb des Iframes, Live-Daten verwenden. Andernfalls verwenden Sie erstellte Daten. const { data } = useQuery(query, params); Rückgabedaten; } „

Portable Text: Lösung des „dangerouslySetInnerHTML“-Problems

Wenn Sie Redakteure HTML schreiben lassen, zerstören sie Ihre Website. Sie werden ein „script“-Tag einfügen. Sie werden 5 „h1“-Tags verwenden (was SEO zerstört). Sanity verwendet Portable Text. Es handelt sich um eine JSON-basierte Spezifikation für Rich Text.

„json [ { „_type“: „Block“, „Stil“: „normal“, „Kinder“: [ { “text”: “Hallo ” }, { “text”: “World”, “marks”: [“strong”] } ] } ] „

Wir rendern dies mit einer Serializer-Komponente. Das gibt uns die totale Kontrolle.

„tsx import { PortableText } from ‘@portabletext/react’;

const-Komponenten = { // Überschreibe, wie H1 gerendert wird Block: { h1: ({children}) =>

{children}

, }, // Benutzerdefinierte Einbettungen Typen: { instagramPost: ({value}) => , productCard: ({value}) => } };

export const RichText = ({ content }) => ( ); „ Sicherheit: Es ist kein XSS (Cross Site Scripting) möglich. Die Struktur ist streng typisiert.

Die Image-Pipeline

Bilder sind der schwerste Teil jeder E-Commerce-Website. Sanity verfügt über ein integriertes Image-CDN. Wenn ein Redakteur eine 50 MB große TIFF-Datei hochlädt, speichert Sanity sie. Die API ermöglicht es uns, die Umwandlung im laufenden Betrieb anzufordern.

https://cdn.sanity.io/images/.../my-image.jpg?w=800&h=600&fit=crop&auto=format

Wir erstellen eine wiederverwendbare „Image“-Komponente, die dies nutzt:

Hotspot & Zuschneiden: Der Editor legt den „Fokuspunkt“ auf dem Gesicht des Modells fest. Wenn wir auf ein Quadrat zuschneiden, wird das Gesicht automatisch zentriert.
Automatisches Format: Stellt AVIF für Chrome, WebP für Safari und JPEG für Legacy bereit.
LQIP (Low Quality Image Placeholder): Die Metadaten enthalten eine Base64-codierte Unschärfezeichenfolge. Wir zeigen dies sofort an, während das Hauptbild geladen wird.

„tsx // urlBuilder.ts imageUrlBuilder aus „@sanity/image-url“ importieren;

const builder = imageUrlBuilder(client);

Exportfunktion urlFor(source) { return builder.image(source).auto(‘format’).fit(‘max’); } „

Schema Engineering: Validierungen

Wir behandeln Inhaltsmodelle wie Datenbankschemata. Wir setzen Regeln durch. „Eine Produktbewertung muss eine Bewertung zwischen 1 und 5 haben.“

„Typoskript // schemas/review.ts defineField({ Name: ‘Bewertung’, Typ: ‘Nummer’, Validierung: (Regel) => Rule.required().min(1).max(5).error(“Bewertung muss 1-5 sein”) }) „ Diese Validierung wird im Studio ausgeführt. Der Redakteur kann physisch keine fehlerhaften Daten veröffentlichen. Der Frontend-Code muss niemals „Bewertung: 200“ verarbeiten.

Internationalisierung (i18n)

Luxusmarken sind global. Es gibt zwei Strategien in Sanity:

Feldebene: { title: { en: „Hello“, fr: „Bonjour“ } }
- Pro: Behält alles in einem Dokument. Gut für starke, konsistente Layouts.
- Contra: Das Dokument wird riesig.
Dokumentebene: Dokument „Title_EN“ und Dokument „Title_FR“.
- Pro: Völlige Freiheit pro Markt. Die französische Seite kann andere Abschnitte haben als die US-Seite.
- Nachteil: Die Synchronisierung ist schwieriger zu verwalten.

Wir empfehlen typischerweise Feldebene für „Globaler Inhalt“ (Produktbeschreibungen) und Dokumentebene für „Marketingseiten“ (Kampagnen unterscheiden sich häufig je nach Region).

10. Sanity Connect für Shopify (Synchronisierung)

Sie möchten keine Produkttitel von Shopify nach Sanity kopieren und einfügen. Wir nutzen Sanity Connect. Es hört auf Shopify Webhooks. Bei Preisaktualisierungen in Shopify -> Synchronisierung mit Sanity. Aber wir machen es in Sanity schreibgeschützt. Der Redakteur sieht die Produktdaten, kann in einem Lookbook darauf verweisen, kann aber den Preis nicht ändern. Dadurch bleibt die „Single Source of Truth“ (Shopify) erhalten und gleichzeitig wird die „Presentation Layer“ (Sanity) bereichert.

11. Benutzerdefinierte Studio-Dashboards

Das CMS ist das Zuhause für das Marketingteam. Wir erstellen benutzerdefinierte Dashboard-Widgets im Studio.

Google Analytics-Widget: „Top 5 Blogbeiträge dieser Woche“.
Shopify-Widget: „Live-Verkaufsticker“.
Vercel-Build-Status: „Wird die Site bereitgestellt?“ Dadurch wird das CMS zu einem Command Center, sodass Sie sich nicht mehr bei fünf verschiedenen Tools anmelden müssen.

13. Migrationsstrategien: WordPress zu Sanity

Die Migration von 5.000 Blogbeiträgen von WordPress ist beängstigend. Wir verwenden keine „Import-Plugins“. Wir schreiben Drehbücher.

Extrahieren: Stellen Sie eine Verbindung zur WP REST API her. Ziehen Sie alle Beiträge.
Transformieren: HTML-Körper konvertieren -> Tragbarer Text (mit „@portabletext/to-portabletext“).
- Dadurch werden „“-Tags in „Marken“ umgewandelt.

Laden: Transaktionales Schreiben (100 Dokumente pro Transaktion). Ergebnis: Ein sauberer, strukturierter Datensatz aus einer chaotischen HTML-Suppe.

14. Das „Content Lake“-Konzept

Warum es einen „See“ nennen? Weil du alles hineinwirfst. Produkte. Mitarbeiterprofile. Filialstandorte. Rechtliche Richtlinien. In einem herkömmlichen CMS sind diese isoliert. In Sanity sind es nur Dokumente. Sie können einen „Geschäftsstandort“ mit einem „Mitarbeiterprofil“ und einem „Produkt“ verknüpfen. „Dieses Produkt ist im Pariser Store erhältlich, der von Chloe geführt wird.“ Diese Graph-Funktion ermöglicht unglaublich umfangreiche Frontend-Erlebnisse, die WordPress nicht modellieren kann.

15. Fazit

Vernunft ermöglicht es uns, das „Was“ (Inhalt) vom „Wie“ (Präsentation) zu entkoppeln. Es verwandelt das CMS von einem Flaschenhals in eine API. Für einen Entwickler fühlt sich das Abfragen von Inhalten mit GROQ wie eine Supermacht an. Für einen Redakteur fühlt es sich wie Magie an, seine Änderungen live zu sehen, ohne auf „Aktualisieren“ zu klicken.

Unzufrieden mit Ihrem CMS?

Wenn Ihr Marketingteam jedes Mal, wenn es einen Blogbeitrag veröffentlicht, das Layout unterbricht. Beauftragen Sie unsere Architekten.