Q: Headless or decoupled. What’s the difference?

A headless CMS , as opposed to a traditional CMS, omits the frontend and is not bound by a specific delivery channel, such as a website. There is no presentation, no frontend development toolset out-of-the-box. In other words, there is no head – hence the name. In a headless platform, the content is made available to be consumed via APIs and you can have anything on the receiving end: websites, mobile apps, AR and IoT devices and various integrations with third-party systems. Unlike Headless, a Decoupled CMS has kept the publishing tools of traditional content management, meaning it has a frontend layer and frontend development tools are available right out of the box. A decoupled CMS has an architecture that clearly separates the management and storage of content from the pages and templates that display it. That is to say, the presentation (frontend) is decoupled from the backend. The two layers communicate via APIs. A set of endpoints expose the content to one or many consumers, from websites that can be developed with the built-in toolset (widgets, templates and the like) to various platforms and frontend frameworks that can take in and interpret the data in the API responses.

Q: Are the Sitefinity .NET Core widgets open sourced and can I override their default behavior?

The widgets are open sourced and available in GitHub . You can customize and extend them to fit your specific use case.

Question 1

Do I need Sitefinity development skills to create different client-side applications?

Accepted Answer

Sitefinity’s decoupled architecture lets you play to your frontend development strengths. Not only can you host Sitefinity on a different server or VM altogether, but your frontend development is not bound by the inherent technologies. Of course, .NET Core development skills are a great asset as they let you create solutions for both web and mobile.

Just like the backend and presentation are decoupled in Sitefinity, you can balance or separate the frontend and backend development in a way that gives you the highest flexibility and shortest time to market.

Question 2

What FE frameworks can Sitefinity work with?

Accepted Answer

A decoupled renderer application built on .NET is available out of the box. Leveraging the content APIs that connect the .NET frontend application with the Sitefinity backend, other renderers can consume Sitefinity content just as easily. These stand-alone renderer applications can be built on JS (Angular, React, Gatsby, Vue) or .NET frameworks (Blazor). Sitefinity DX comes with pre-packaged samples to kickstart your frontend development for Angular, React and Blazor.

Question 3

How does Sitefinity enable use of content across platforms and devices?

Accepted Answer

In traditional CMS terms, the content you create is rendered on web pages and delivered to the visitors of your website. However, modern digital users need to be engaged across multiple channels. An organization can have as many front-end, customer facing solutions as it wants and has the skillset and resources to develop, but creating and managing content for each of them separately is a massive challenge with dubious results. You’re more likely to end up with siloed data, as well as cross-team dependencies and bottlenecks rather than a consistent messaging and user experience

A decoupled and API-driven CMS, such as Sitefinity, lets savvy organizations reuse, repurpose and leverage content to reach audiences across channels, devices and platforms.

Content management decoupled from presentation: frontend application can be deployed independently for faster development, tighter security, platform independence and framework flexibility.
Web services to fetch, store and deliver content: create and edit content in a single place, then leverage a robust set of native and standard-compliant OData APIs to deliver it to a broad set of consumers in a universally readable, frontend-agnostic format.

Question 4

What’s an API-first approach? API-driven content management?

Accepted Answer

Sitefinity has been an API-first CMS since the v4.0 release all the way back in 2010 when the content management was completely detached from the page and template editing. The page layout and the widgets created by designers and developers consume the content created by editors. Alongside the native data services, Sitefinity provides a robust set of OData Rest APIs for all prebuilt and dynamically created content types in the system.

OData is a powerful open-source and open protocol technology that defines a set of best practices for building and consuming RESTful APIs. Client applications such as SPAs, mobile apps, IoT devices can easily consume content by using a standardized REST API calls or by taking advantage of the Sitefinity WebServices SDK.

Introduced in Sitefinity 12.2, OData services can also be used to retrieve metadata such as web page structure and use this metadata to build applications that consume the page layout and content created in the CMS. This approach is the foundation of the new out-of-the box frontend layer of Sitefinity built on .Net Core.

Question 5

Headless or decoupled. What’s the difference?

Accepted Answer

A headless CMS, as opposed to a traditional CMS, omits the frontend and is not bound by a specific delivery channel, such as a website. There is no presentation, no frontend development toolset out-of-the-box. In other words, there is no head – hence the name. In a headless platform, the content is made available to be consumed via APIs and you can have anything on the receiving end: websites, mobile apps, AR and IoT devices and various integrations with third-party systems.

Unlike Headless, a Decoupled CMS has kept the publishing tools of traditional content management, meaning it has a frontend layer and frontend development tools are available right out of the box. A decoupled CMS has an architecture that clearly separates the management and storage of content from the pages and templates that display it. That is to say, the presentation (frontend) is decoupled from the backend. The two layers communicate via APIs. A set of endpoints expose the content to one or many consumers, from websites that can be developed with the built-in toolset (widgets, templates and the like) to various platforms and frontend frameworks that can take in and interpret the data in the API responses.

Question 6

What are the benefits of separating content management from presentation?

Accepted Answer

An architecture built on separation of concerns has multiple positive effects on administration, development, hosting, deployment and scalability.

The content you create can be reused and easily delivered and maintained across multiple frontend consumers. Whenever content is updated, it’s ready to be consumed via APIs by any frontend framework you choose to employ. Content editors have a high level of flexibility and independence, meaning developers on the other hand are free to explore more and better ways to improve the user experience and leverage diverse frontend technologies.

The Renderer app communicates with your Sitefinity application through a set of APIs. via the C# RestSdk package (Progress.Sitefintiy.RestSdk). This minimizes the margin of error and reduces the risk of vulnerabilities in frontend development. Additional API endpoints can be exposed from Sitefinity CMS to cover custom use cases.

Question 7

Can I get training in Sitefinity and .NET Core development?

Accepted Answer

We have a dedicated, on-demand training course, where you will learn how to use Sitefinity from a developer standpoint. Get familiar with.NET Core in depth, learn how to develop widgets, templates, and more.

Foundations of Sitefinity Development

Question 8

Are the Sitefinity .NET Core widgets open sourced and can I override their default behavior?

Accepted Answer

The widgets are open sourced and available in GitHub. You can customize and extend them to fit your specific use case.

Question 9

What’s the best way to migrate to .NET Core?

Accepted Answer

The .NET Core Renderer does not limit you to working with .NET Core pages only. Using the Renderer, you can simultaneously work with .NET Core and MVC pages and maintain websites with a mixed collection of rendering solutions. This way, you can migrate your current website page by page.

For more information, see Migrate Pages to .NET Core. You’re welcome to also review the complete Sitefinity .NET Core Renderer product documentation.

Question 10

What makes .NET Core the preferred choice of the Progress Sitefinity team?

Accepted Answer

.NET Core follows the latest programming patterns and allows us to deliver features quite fast&mdash;developing new widgets is a prime example. The .NET Core renderer is not coupled with an old technology stack and will boost your developer productivity. At the same time, it has introduced a full WYSIWYG page and form building experience for content editors.

Question 11

What are the benefits of the .NET Core renderer and the decoupled Sitefinity architecture?

Accepted Answer

The .NET Core renderer in Sitefinity DX is a stand-alone .NET Core application that can be deployed and hosted anywhere. You can bring your IDE of choice and code against it. When developing new features and functionality, you work on the presentation layer of Sitefinity only, which lets you iterate at a higher speed. The build and deployment time is markedly shorter.

The Renderer app communicates with your Sitefinity application through a set of APIs. via the C# RestSdk package (Progress.Sitefintiy.RestSdk). This minimizes the margin of error and reduces the risk of vulnerabilities in frontend development. Additional API endpoints can be exposed from Sitefinity CMS to cover custom use cases.

The development model employs the same concepts of widget, widget designers and template development as MVC. With the .NET Core renderer, we are leveraging view components, layout files and predefined building blocks, allowing no-code widget configuration. The extensive product documentation contains many sample widgets demonstrating the development model.

Question 12

I have a new project. Should I start implementing it with .NET Core?

Accepted Answer

We strongly recommend that you carefully evaluate .NET Core and its features since it has many superior capabilities compared to MVC. This way, you’ll be able to make an informed decision about which technology better matches your requirements. Although the total number of OOB widgets for MVC is higher at first glance, many widgets in .NET Core are folded into one (e.g., ContentList vs stand-alone News and Blogs widgets). Besides , with the new widget designers, you can quickly create custom widgets.

Question 13

Will existing MVC projects/pages continue running into .NET Core, so my team can slowly transition to .NET Core?

Accepted Answer

Yes, it is perfectly OK to use your existing MVC pages with .NET Core. In this case, the .NET Core renderer will act as a proxy and serve the MVC pages to the client, so you can have MVC and .NET Core pages within the same project trouble-free. This approach is especially helpful when trying to migrate existing projects to .NET Core.

As for mixing different types of widgets, you cannot place your existing MVC or WebForms widgets on a.NET Core page or template. Only .NET Core widgets can exist on .NET Core pages. Keep in mind that the paradigms of MVC and ViewComponents are similar enough for some code to be reused.

Question 14

What is the deployment model of the new architecture?

Accepted Answer

Since the backend and the frontend are decoupled, you will need to host two applications: one for the backend and one for the frontend. This sort of separation of concerns allows greater scalability and faster iterations at the frontend.

Question 15

Which version of .NET Core is supported?

Accepted Answer

We are supporting the latest version, .NET 7, and our plan is to always keep up with the framework&rsquo;s upgrade cycle.

Decoupled Net Core

Sitefinity Decoupled CMS

Sitefinity Net Core

Sitefinity

NativeChat

MOVEit

Kendo UI

Telerik

DataDirect

Corticon

Kemp LoadMaster

Flowmon

WhatsUp Gold

Kendo UI

Telerik

Test Studio

Fiddler Everywhere

Chef

DataDirect

MOVEit

WS_FTP

OpenEdge

MarkLogic

Semaphore

Sitefinity Decoupled CMS

Sitefinity Net Core