Das Routing in einer Webanwendung ist der Prozess, bei dem ein bestimmter URL-Pfad einer gerenderten Seite zugeordnet wird. Catalyst verfügt über ein vorgefertigtes, festgelegtes Routing-Schema für alle wichtigen Storefront-Seitentypen. BigCommerce-Produkte, -Kategorien, -Marken und -Webseiten haben jeweils einen URL-Pfadwert. Diese Pfade sind in verschiedenen Mustern verfügbar, je nach Ihren Einstellungen unter „Einstellungen > Allgemein > URL-Struktur“. Die Architektur des Routings in BigCommerce Catalyst stellt sicher, dass die URLs im Shop genau mit diesen Pfaden übereinstimmen. In einem Catalyst-Shop finden Sie das Produkt mit dem URL-Pfad /sample-orbit-terrarium-small/ unter dem absoluten Pfad mystore.com/sample-orbit-terrarium-small/.
Struktur der Routing-Dateien
Werfen wir einen kurzen Blick auf die wichtigsten Routing-Dateien und Verzeichnisse in Catalyst. Da Bigcommerce Catalyst den Next.js App Router nutzt, befinden sich die Routing-Dateien im Verzeichnis „app“. Zu den Verzeichnissen, die den URL-Mustern entsprechen, gehören:
- admin – Eine einfache Route, die zum Kontrollpanel des BigCommerce-Shops weiterleitet.
- api – Enthält Routen für einige API-Endpunkte, beispielsweise solche, die mit der Kundenauthentifizierung zusammenhängen.
- sitemap.xml – Enthält die Route zur Erstellung der Sitemap.
- [locale]/maintenance – Die Seite, die angezeigt wird, wenn der Shop inaktiv ist.
- [locale]/(default) – Eine Next.js-Routengruppe, die für alle anderen Seiten der Shop-Oberfläche gilt. Die URL-Pfade enthalten den Verzeichnisnamen (default) nicht als Segment. Die Datei „layout.tsx“ in diesem Verzeichnis enthält ein gemeinsames Layout für alle typischen Seiten.
Innerhalb von [locale]/(default) gibt es weitere bemerkenswerte Routengruppen:
- (auth) – Eine Gruppe, die alle Routen für die Kundenregistrierung, die Anmeldung und das Zurücksetzen des Passworts umfasst.
- (faceted) – Eine Gruppe, die alle Routen umfasst, bei denen eine Facettenfilterung der Produktliste zum Einsatz kommt, sowie die Serverkomponenten und die allen diesen Routen gemeinsame Logik.
Zu den wichtigsten Storefront-Routen und ihren Speicherorten unter „app/[locale]/(default)“ gehören:
- page.tsx – Startseite
- (auth)/login/page.tsx – Anmeldeseite
- (auth)/register/page.tsx – Registrierungsseite
- (faceted)/category/[slug]/page.tsx – Kategorieseite
- (faceted)/brand/[slug]/page.tsx – Markenseite
- (faceted)/search/page.tsx – Suchergebnisseite
- product/[slug]/page.tsx – Produktdetailseite
- cart/page.tsx – Warenkorbseite
- account/* – Seiten im Bereich „Kundenkonto“
- compare/page.tsx – Produktvergleichsseite
- webpages/normal/[id]/page.tsx – Standard-Webseiten
- webpages/contact/[id]/page.tsx – Kontakt-Webseite
Benutzerdefinierte URL-Middleware
Next.js-Middleware kann Anfragen blockieren, bevor sie eine bestimmte Route erreichen, und sie dabei ändern oder umleiten. Der zentrale Einstiegspunkt für Middleware – „middleware.ts“ – lädt mehrere Middleware-Funktionen und führt sie aus. Die für Sie wichtigste Middleware ist jedoch diejenige, die sich auf benutzerdefinierte URLs bezieht.
Beachten Sie das Muster der Dateipfade für die meisten Routen, wie oben erläutert. Es umfasst feste URL-Segmente wie „product“ und dynamische Segmente wie „[slug]“ oder „[page]“. Werfen Sie einen Blick auf die Logik in der Routendatei für die Produktdetailseite. Sie werden feststellen, dass der Parameter „[slug]“ eigentlich die numerische ID eines Produkts sein soll.
Das bedeutet, dass die Route tatsächlich einer URL wie „mystore.com/product/123“ entsprechen würde. Dies stimmt nicht mit den erwarteten URL-Pfaden für Produkte, Kategorien usw. überein, die wir zuvor betrachtet haben. Wir erwarten URLs wie mystore.com/sample-orbit-terrarium-small/. Solche URLs enthalten keine Angaben dazu, ob sie einem Produkt, einer Kategorie, einer Marke oder einer Webseite entsprechen. Catalyst nutzt Middleware, um solche Anfragen abzufangen und ihr endgültiges Routing zu bestimmen.
Die Datei middlewares/with-routes.ts enthält die Logik für diese Umleitung. Sie sendet zunächst eine GraphQL-Anfrage, um den Typ und die ID der Entität abzurufen, die der Route entspricht. Diese Informationen werden dann verwendet, um den URL-Pfad der Anfrage so „umzuschreiben“, dass Next.js den Pfad als etwas Ähnliches wie das obige Beispiel /product/123 interpretiert und die Anfrage an die endgültige passende Route weiterleitet.
Strategien zur Verbesserung der Routing-Leistung
Die Catalyst-Routing-Architektur und die benutzerdefinierte URL-Middleware umfassen einige wichtige Strategien. Diese sind darauf ausgelegt, das Routing und die Darstellung von Seiten so schnell wie möglich zu gestalten.
KV-Speicher
Die oben beschriebene Logik zur Ermittlung des endgültigen Routing-Pfads einer dynamischen URL erfordert eine zusätzliche GraphQL-Anfrage. Diese muss synchron und vor dem Abruf der Hauptdaten für den Inhalt einer bestimmten Seite durchgeführt werden. Es handelt sich dabei zudem nicht um die einzige Anfrage dieser Art. Dieselbe Middleware fragt auch den Status des Shops ab, um festzustellen, ob die Wartungsseite bereitgestellt werden soll. Diese zusätzlichen Roundtrips zur BigCommerce-API können die Ladezeiten der Seiten erheblich beeinträchtigen.
Um diesen Prozess zu optimieren, nutzt Catalyst einen Schlüssel-Wert-Speicher (KV-Store), um die Ergebnisse dieser GraphQL-Anfragen zu Routen und zum Shop-Status zwischenzuspeichern. In lokalen Entwicklungsumgebungen handelt es sich bei der für diesen Speicher verwendeten Implementierung um ein einfaches JavaScript-Map-Objekt, das keinen spezifischen Zweck erfüllt. In Produktionsumgebungen wird jedoch eine echte KV-Datenbank-Implementierung erwartet. Das bedeutet in der Praxis, dass nur bei einem kleinen Teil der Seitenrenderings jemals die GraphQL-Anfragen zum Shop-Status und zu den Routeninformationen für einen bestimmten Pfad gestellt werden müssen.
Catalyst bietet integrierte Unterstützung für Upstash for Redis, den auf Vercel verfügbaren Standardspeicher. Es ist jedoch einfach, einen eigenen Speicher zu implementieren. Im Folgenden sind wichtige Komponenten für den KV-Speicher in der Anwendung aufgeführt:KV-Speicher
Übersetzt mit DeepL.com (kostenlose Version)
- lib/kv/adapters – Enthält die integrierten Adapter. Wenn Sie sich die Adapter-Dateien in diesem Verzeichnis ansehen, werden Sie feststellen, dass es sich bei jeder einzelnen um eine äußerst schlanke Implementierung der Schnittstelle „KvAdapter“ handelt.
- lib/kv/index.ts – Die Funktion „createKVAdapter“ in dieser Datei enthält die Logik zur Auswahl eines KV-Adapters.
Teilweises Vorrendering
Catalyst nutzt das partielle Vorrendering (PPR) von Next.js, damit Seitenrouten statische und dynamische Inhalte kombinieren können. Das bedeutet, dass Seiteninhalte, die nicht von dynamischen Daten abhängen – wie beispielsweise die Seite , die CSS und JavaScript lädt –, so schnell wie möglich bereitgestellt werden können. Dabei wird nicht auf das Rendern von Inhalten gewartet, die auf dynamischen Daten beruhen.
Catalyst nutzt PPR, um im gesamten Shop die bestmögliche Seitenladeleistung zu erzielen. Zu den wichtigsten Bereichen, in denen Sie Konfigurationen im Zusammenhang mit PPR finden, gehören:
- next.config.js – Im Konfigurationswert „experimental.ppr“
- app/[locale]/(default)/layout.tsx – Mit dem Ausdruck „experimental_ppr = true“
Um PPR effektiv nutzen zu können, sollten Komponenten, die dynamische Daten verwenden, mit React Suspense kombiniert werden. Catalyst setzt diese Strategie vor allem über die Stream-Komponente um.
Bitte kontaktieren Sie uns unter wargis@bay20.com/manish@bay20.com oder rufen Sie uns unter +91-8800519180 / +91-9582784309 an, wenn Sie Unterstützung im Zusammenhang mit Bigcommerce benötigen. Sie können auch die Bigcommerce-Entwicklungsseite besuchen, um sich über unsere Dienstleistungen zu informieren.
