[Progress News] [Progress OpenEdge ABL] Moving Toward a Decoupled CMS With .NET Core in Sitefinity

Status
Not open for further replies.
L

Lilia Messechkova

Guest
In this article, I want to give you a preview of our vision of how Sitefinity can be used to rapidly develop and deliver multichannel experiences utilizing .NET Core MVC.

Why ASP.NET Core?


ASP.NET is a popular web-development framework for building web apps on the .NET platform. .NET Core is the open-source version of ASP.NET, that runs on macOS, Linux, and Windows. .NET Core was first released in 2016 and is a re-design of earlier Windows-only versions of ASP.NET.

It enables developers to deliver APIs quickly, has tools to simplify development processes and we plan to add it to Sitefinity.

Sitefinity Today


Let’s look at today’s Sitefinity. It’s a powerful, traditional CMS with headless capabilities:


Traditional CMS Capabilities for Website Creators to Deliver With Server-Side Technology

Headless CMS for Developers to Build Rich Client-Side Applications

Headless “Plus”

  • WYSIWYG content editor
  • Layout templates
  • Resource packages
  • REST API for content
  • Admin UI built on top
  • REST API content
  • CRUD
  • Lifecycle and workflow
  • Permissions
  • Preview code and what content editors are building in parallel in the staging environment



To give you the best of all worlds—the traditional plus the powerful REST APIs—we’ll decouple the frontend and move it to .NET Core enabling it to communicate with those powerful APIs.

Our Strategy


Sitefinity hosting architecture today is based on two tiers. Tier 1 hosts database services. Tier 2 hosts the backend services, which serve backend content editing requests, and the page rendering engine, which serves the requests of the frontend user.

We envision moving to a three-tier architecture, where Tiers 2 and 3 communicate with one another via REST:


Tier 1

Tier 2

Tier 3

Database Services​

Backend Admin


Frontend Services​



The benefits of a three-tier architecture:

  • Faster development—Customize the frontend without having to deal with the backend
  • Easier upgrades—All customizations will be isolated, so the backend services can be upgraded quickly
  • Isolation between website and administration—Increases system security and reliability
  • Extensibility for other rendering engines and IDE—With the frontend application based on .NET Core, IT administrators can host the app on any platform supported by .NET Core.
  • Less expensive scalability—The frontend application will be much smaller and lightweight, requiring fewer resources to run. When you scale, you can use less powerful machines.

In practical terms, imagine that you need to change a widget. In a two-tier architecture, since the backend and frontend are running in the same process, you need to restart the entire system and wait for reinitialization.

In a three-tier scenario, when you deploy or run the application to see the outcome, you only need to restart the frontend. The backend processes stay up and running throughout.

Scalability Benefits


In a two-tier architecture, if you’re experiencing a heavy user load and you must scale, you need to duplicate the application on the next node you want to add. That means scaling the front and backend because they live in the same application.

In three tiers, you have different applications hosted on separate environments, meaning you can scale only what you need, when you need it.

Next Steps – Additional Refinements


The next steps we envision toward decoupled rendering include:

  • ASP.NET Core widget development framework
  • Out-of-the box widget designers based on Angular 2
  • .NET Core-powered renderer and page editor
  • A page layout REST API
  • Backend customization implemented as microservices

Stay tuned as we launch these exciting new improvements across coming Sitefinity releases! www.progress.com/sitefinity-cms and Sitefinity CMS Documentation

Continue reading...
 
Status
Not open for further replies.
Top