Sitecore 10 has arrived, introducing an exciting new developer experience known as Sitecore Headless Development. You might wonder, “Didn’t Sitecore already have a Headless setup in Sitecore 9?” The answer is yes, it still exists and is referred to as Sitecore Javascript Services (JSS). What sets this apart is that the rendering layer now relies on ASP.NET Core instead of JavaScript libraries like Angular, VueJS, and React. This means you can enjoy the benefits of a headless setup without the need to code in different languages for the backend (C#) and the front end (JS). It’s now all about C#.
Before delving further into this new experience, let’s clarify one thing: Like Sitecore JSS, this isn’t a true headless setup; it’s decoupled. The distinction lies in a headless CMS having no rendering engine and serving content to various endpoints, such as websites, apps, or physical display boards. Headless systems usually lack features like content preview because they have no knowledge of how the content will be displayed. In contrast, decoupled systems maintain a rendering engine but separate it from the backend. However, the term “headless” is currently in vogue, and Sitecore has adopted this terminology.
HOW DOES IT WORK?
The traditional aspects of Sitecore remain much the same. You still have Content Manager and Content Delivery servers, XConnect, Identity, and all other roles that existed in Sitecore 9. However, instead of creating View and Controller Renderings in Sitecore to generate HTML, you will now create JSON renderings that provide item data via an API.
A new Rendering Host layer built in ASP.NET Core communicates with this API. When a visitor comes to your site, they interact with the ASP.NET Core site, which in turn calls the Headless Service API on your content delivery server. This API returns JSON objects containing item data, which the ASP.NET Core site then uses to render the page and serve it to the visitor.
This might initially sound like more work because you need to set up a separate ASP.NET Core site and establish communication with an API. However, Sitecore has developed a Sitecore ASP.NET Rendering SDK (available via NuGet) to simplify most of the API interactions. You’ll primarily need to map a View in the Rendering Host to a Layout Rendering item in Sitecore, with the SDK handling the rest.
WHAT ARE THE ADVANTAGES?
As a developer, there are three significant advantages to this setup:
- Easier Installs and Upgrades: Sitecore installations can be complex, with numerous configurations. However, by separating the rendering host from the Sitecore installation, there’s less need to modify what’s set up during installation. While changes to the CM and CD instances will still be necessary, they’ll be more manageable.
- Visual Studio Integration: With this setup, you can run and debug directly from Visual Studio, eliminating the need for the cumbersome process of publishing, debugging, and restarting Visual Studio.
- Front End Developer-Friendly: Front end developers working on Sitecore usually face challenges. In a decoupled setup, they only need the ASP.NET Core Rendering Host project, which runs directly from source control without additional installations, even on a Mac.
HOW TO GET STARTED?
Getting started is relatively straightforward, thanks to Sitecore’s provided templates and guides. They offer a getting started template and a guide for creating your first model-bound view. Additionally, Sitecore Container setup (introduced in Sitecore 10) simplifies the process, reducing the need for various prerequisites like Solr with HTTPS and debugging SIF errors. If you encounter issues related to container ports, the documentation provides additional port numbers to check. Once set up, you may have more questions about containers, but the rendering host portion generally works well.
Source: https://himynameistim.wordpress.com/2020/08/28/sitecore-10-with-headless-asp-net-core/
𝘛𝘦𝘤𝘩 𝘚𝘰𝘭𝘶𝘵𝘪𝘰𝘯 𝘏𝘶𝘣 
Deixe um comentário