Stream URL Handling Concept

Status: Accepted


  • URLs for items (product, category, etc.) will be generated on the server exclusively
  • A handler concept will be implemented in PHP to generate and parse back this information from a URL that permits / in some URL parts
  • In order to link to an item (aka its master page) the item needs to be available and a JS component will simply use the link
  • Generated URLs will still have a predefined format (e.g. /.+/p/{sku} so that the JS router can handle it at least to some degree
  • URLs that have URL parameters (?) will be excluded from SEO indexing by appending a _nocrawl parameter and forbidding this from the robots.txt



  • URLs should be speaking (nice to read and remember)
  • A URL can be sent to someone else producing the same screen (e.g. showing a page with the same products)


  • URLs should not only contain an ID but also keywords, e.g.

  • NOT: /p/2744rf438-gu34r8374rfhe5485tgu

  • YES: /sonnenbrille/schwarz/armani/fancy-modell
  • OK: /sonnenbrille/armani/fancy-modell/p/2744756573473

  • Ideally URLs should be adjustable by the marketing person


  • URL must identify a view uniquely
  • Parameters for underlying streams must be encoded in the URL

  • There might be multiple streams in one view so parameters must be distinguished between streams

Base URLs

A URL in Frontastic addresses one of these items:

  • a) Stage node
  • b) Dedicated master page (e.g. "cart")
  • c) Master page of a generic item (e.g. "product" or "category")

Each of these requires a speaking URL. For a) and b) the URL is simply defined by the Backstage user as a config value when creating the corresponding node. (Hint: We might think about a history for URL changes to perform proper redirects)

!!! TODO: Multi-lingual URLs

For c) the situation is more complex because the URLs need to be generated and resolved automatically by Fronastic on basis of the data of the item. In order to allow full flexibility for the implementor when generating the URLs we will implement the following mechanism:

  • Master-Page controllers for items match on a specific route that allows slashes in parts of the URL

  • e.g. /.+/p/{sku} for a product (allows /5th-avenue/brillen/damen/schwarz/p/6921103620169)

  • e.g. /.+/c/{identifier} for a category (allows /c/brillen-kinder)

  • Per item, a mechanism on PHP site is registered which performs 2 tasks:

  • Generate a URL for an item

  • Parse a corresponding API query object from a given URL

  • We will call the method 1. for each item that is fetched through our APIs and inject the URL into the response data that is sent to the client

  • JS components can then simply realise a link by using the link that is already available in the item data (e.g. product.url or category.url or in future content.url)

  • The JS router will still be able to reverse parse the route to instruct a corresponding master-page fetch

  • When an API call to fetch an item from the front-end is coming in to the PHP stack, method 2. is called to factor the query for fetching the item

  • On the basis of this item, the corresponding master page is then selected and returned

Apollo implementation

For Apollo, the mechanisms to generate and parse URLs will be very simple. The Apollo SIM (PIM) will provide each product/category with a meaningful slug in the format some_thing_fancy and our handling will translate that to /some/thing/fancy/p/<sku> (for a product). The reverse will then create a corresponding ProductAPI query for the SKU.

URL Parameters

URL parameters in Frontastic are used to carry around different information:

a) Stream configuration additions b) Page state indicators (prefixed with _ to not be sent to the server)

By default, Frontastic will append the parameter _nocrawl to all URLs with parameters and have URLs with _nocrawl excluded from being crawled by robots.txt. This avoids filter URLs to appear in search indexes.

Still Open Challenges

  • Multilingual URLs

  • In multilingual projects, we will most probably be required to have multilingual SEO-URLs, e.g.

    • /sonnenbrillen
    • /sunglasses
  • Backstage does not support this yet

  • The HTML hreflang attribute should be implemented with this info

  • We currently append parameters to the URL which are part of the current context (e.g. environment). We need to get rid of this.

  • How do we determine if the context differs from default to indicate when such information is required to be added to the URL?