When leveraging Sitecore headless services, content and layout are centrally managed within the Sitecore platform and are subsequently exposed to applications through its “layout service.” Consequently, the live website is not directly served by Sitecore CD’s (Content Delivery servers) but by a dedicated rendering host, which is commonly implemented using technologies such as Node.js or ASP.NET Core. Sitecore facilitates this integration seamlessly by providing software development kits (SDKs), empowering developers to effortlessly incorporate the layout service into their solutions.

New website with a headless
When constructing a new website with a headless approach, you can easily direct the domain name system (DNS) to your designated rendering host. In this setup, Sitecore exclusively manages content and layout details through its layout service. For pre-existing Sitecore sites developed using MVC, a seamless coexistence is achievable. This is attributed to the rendering host’s capability to selectively handle requests solely for the distinct headless site, ensuring there are no conflicts when concurrently serving traditional and headless sites side by side.

Enabling functionality on a single site

If you currently have an existing site and aim to integrate new headless features seamlessly without opting for a separate domain, employing a reverse proxy provides an effective solution. Platforms like Azure offer a straightforward solution through tools like Front Door. In this setup, incoming requests are directed to Front Door, which intelligently routes them based on the specified path. This ensures a smooth integration of headless features by channeling requests to either the headless rendering host or your Sitecore Content Delivery servers, all orchestrated seamlessly through the reverse proxy mechanism.

This approach also provides a gradual transition of current features to a headless architecture, eliminating the need for a comprehensive rebuild. To facilitate this transition, duplicating header and footer components may be necessary, yet they can draw from the same content infrastructure supporting your current MVC/Sitecore solution. Additionally, it’s crucial to address the seamless sharing of session data or authenticated states between the headless solution and the established site.

Leave a Reply

Your email address will not be published. Required fields are marked *