Skip to content

Use the new sw-domain header to reduce Store API calls during SSR #2487

@mkucmus

Description

Technical TODO

Follow-up of shopware/shopware#17301 (related to #1795).

That PR introduces a new optional sw-domain header for the Store API. When a headless client sends the full URL of a domain configured on the sales channel:

GET /store-api/product
sw-access-key: SWSC...
sw-domain: https://shop.example.com/de

the backend resolves the language and currency from that domain on its own - no UUIDs needed. Precedence is preserved: an explicit sw-language-id / sw-currency-id header or a value switched in the context still wins, and an unknown domain returns HTTP 400 instead of silently serving the wrong locale.

Why we need it

It allows us to reduce the number of Store API calls during SSR. Currently in templates/vue-demo-store/app/app.vue the language-syncing flow on a server-side render is:

  1. GET /context - initial session context
  2. GET /language (getAvailableLanguages)
  3. If the locale resolved from the URL prefix differs from the session language:
    • PATCH /context (changeLanguage)
    • GET /context again (refreshSessionContext)

With sw-domain set as a default header (resolved from the current request host + URL prefix), the very first /context response already comes back with the correct language and currency, so steps 3a/3b (and the language-id lookup juggling around them) become unnecessary - up to 2 fewer API calls per SSR render, plus simpler logic in app.vue.

What to do

  • Add support for sending the sw-domain header in the API client / Nuxt module (resolved per-request from the incoming host and locale prefix during SSR)
  • Simplify the language detection logic in app.vue (demo store / starter template) to rely on the domain-resolved context instead of changeLanguage + refreshSessionContext
  • Keep the current flow as a fallback for backends that don't support the header yet (feature is additive and version-dependent)
  • Handle the FRAMEWORK__ROUTING_SALES_CHANNEL_DOMAIN_NOT_FOUND (HTTP 400) error case

Blocked by

Metadata

Metadata

Labels

enhancementNew feature or request

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions