Une plateforme headless, des expériences illimitées

Un CMS headless, par opposition à un CMS traditionnel, n'a pas de front-end et n'est pas lié à un canal de diffusion spécifique, tel qu'un site web. Il n'y a pas de présentation, ni d'outils de développement front-end tout prêts. En d'autres termes, il n'y a pas de tête, d'où son nom. Sur une plateforme headless, le contenu est mis à disposition pour être consommé via des API et tout est permis : sites Web, applications mobiles, dispositifs AR et IoT ainsi que diverses intégrations avec des systèmes tiers.

Contrairement au Headless, un CMS découplé a conservé les outils de publication de gestion de contenu traditionnelle, ce qui signifie qu'il possède une couche front-end et que les outils de développement de cette couche sont disponibles immédiatement. Un CMS découplé possède une architecture qui sépare clairement la gestion et le stockage du contenu des pages et des templates qui l'affichent. En d'autres termes, la présentation (front-end) est découplée du back-end. Les deux couches communiquent via des API. Un ensemble de points de terminaison expose le contenu à un ou plusieurs consommateurs, qu'il s'agisse de sites Web pouvant être développés avec les outils intégrés (widgets, templates, etc.) ou de diverses plateformes et cadres front-end pouvant recevoir et interpréter les données dans les réponses API.

Une architecture fondée sur la séparation des préoccupations a de multiples effets positifs sur l’administration, le développement, l’hébergement, le déploiement et l’évolutivité.

Le contenu que vous créez peut être réutilisé et facilement diffusé et maintenu par plusieurs consommateurs frontaux. Chaque fois que le contenu est mis à jour, il est prêt à être consommé via des API par n’importe quel framework frontal que vous choisissez d’utiliser. Les éditeurs de contenu ont un haut niveau de flexibilité et d’indépendance, ce qui signifie que les développeurs, d’autre part, sont libres d’explorer des moyens plus nombreux et meilleurs d’améliorer l’expérience utilisateur et de tirer parti de diverses technologies frontales.

Le moteur de rendu .NET Core de Sitefinity 13, par exemple, est une application autonome qui peut être déployée et hébergée partout. Il peut fonctionner sur tout système d'exploitation pris en charge par .NET Core et vous pouvez utiliser n'importe quel éditeur de texte. Lorsque vous développez de nouvelles caractéristiques et fonctionnalités, vous travaillez uniquement sur la couche de présentation de Sitefinity, ce qui vous permet d'itérer à une vitesse plus élevée.

L'architecture découplée de Sitefinity vous permet de jouer sur vos forces en matière de développement front-end. Non seulement vous pouvez héberger Sitefinity sur un autre serveur ou une autre VM, mais votre développement front-end n'est pas limité par les technologies qui lui sont inhérentes. Bien entendu, les compétences en matière de développement .NET Core sont un atout majeur, car elles vous permettent de créer des solutions pour le Web et les mobiles.

Tout comme le back-end et la présentation sont découplés sur Sitefinity, vous pouvez équilibrer ou séparer le développement du front-end et du back-end de sorte à vous procurer une plus grande flexibilité et un plus court délai de commercialisation.

Sitefinity est un CMS api-first depuis la version v4.0 en 2010, alors que la gestion du contenu était complètement détachée de l'édition des pages et des templates. La mise en page et les widgets créés par les concepteurs et les développeurs consomment le contenu créé par les éditeurs. Outre les services de données natifs, Sitefinity fournit un ensemble robuste d'API OData Rest pour tous les types de contenu préconstruits et créés dynamiquement dans le système.

OData est une puissante technologie open source et de protocole ouvert qui définit un ensemble de bonnes pratiques pour la création et la consommation d'API RESTful. Les applications clientes telles que les SPA, les applications mobiles, les appareils IoT peuvent facilement consommer du contenu en utilisant des appels d'API REST normalisés ou en tirant parti du kit SDK Sitefinity WebServices.

Apparus sur Sitefinity 12.2, les services OData peuvent également être utilisés pour récupérer des métadonnées telles que la structure des pages web et utiliser ces métadonnées pour construire des applications qui consomment la mise en page et le contenu créés sur le CMS. Cette approche est la base de la nouvelle couche front-end toute prête de Sitefinity construite sur .Net Core.

Un aperçu technique de la suite .NET Core est immédiatement disponible et nous prévoyons de déployer des directives dans les prochaines versions sur la façon de configurer un moteur de rendu front-end personnalisé (côté serveur) tel que Java et Php. L'intégration d'un moteur de rendu Angular dans la suite .Net Core existante est également prévue. Ces outils peuvent fonctionner côte à côte, permettant aux utilisateurs de Sitefinity de créer des widgets et des solutions côté client avec des interfaces utilisateur et des interactions utilisateur riches. Bien entendu, les services OData conformes aux normes et leur modèle de données indépendant de la plateforme favorisent les implémentations headless potentielles dans toute technologie front-end.

Avec un CMS standard, le contenu que vous créez est présenté sur des pages Web et ainsi transmis aux visiteurs de votre site. Or les utilisateurs du numérique contemporain exigent d'être engagés sur plusieurs canaux. Une entreprise peut disposer d'autant de solutions front-end, orientées client, qu'elle le souhaite et dispose des compétences et des ressources pour les développer, mais la création et la gestion de contenu pour chacune d'entre elles séparément est un défi de taille aux résultats douteux. Vous risquez davantage de vous retrouver avec des données cloisonnées, ainsi que des dépendances et des goulots d'étranglement entre équipes, plutôt qu'avec un message et une expérience utilisateur cohérents.

Un CMS découplé et piloté par API, tel que Sitefinity, permet aux entreprises avisées de réutiliser, de réaffecter et d'exploiter le contenu pour atteindre les audiences sur tous les canaux, appareils et plateformes.

• Gestion de contenu découplée de la présentation : l’application front-end peut être déployée indépendamment pour un développement plus rapide, une sécurité renforcée, une indépendance de la plateforme et une flexibilité du framework.
  
  
• Services Web pour récupérer, stocker et diffuser du contenu : créez et modifiez du contenu en un seul endroit, puis tirez parti d’un ensemble robuste d’API OData natives et conformes aux normes pour le fournir à un large éventail de consommateurs dans un format universellement lisible et indépendant du front-end.
  

Le moteur de rendu .NET Core de Sitefinity DX est une application .NET Core autonome qui peut être déployée et hébergée n'importe où. Vous pouvez apporter votre IDE de choix et coder avec celui-ci. Lorsque vous développez de nouvelles caractéristiques et fonctionnalités, vous travaillez uniquement sur la couche de présentation de Sitefinity, ce qui vous permet d'itérer à une vitesse plus élevée. Le temps de construction et de déploiement est nettement plus court.

L'application Renderer communique avec votre application Sitefinity par le biais de plusieurs API, via le package C# RestSdk (Progress.Sitefintiy.RestSdk). Cela minimise la marge d'erreur et réduit le risque de vulnérabilités dans le développement front-end. Des points de terminaison API supplémentaires peuvent être exposés à partir de la plateforme CMS Sitefinity pour couvrir des cas d'utilisation personnalisés.

Le modèle de développement utilise les mêmes concepts de widget, de concepteurs de widgets et de développement de modèles que MVC. Avec le moteur de rendu .NET Core, nous tirons parti des composants de vue, des fichiers de mise en page et des blocs de construction prédéfinis, ce qui permet une configuration des widgets sans code. La documentation détaillée du produit contient de nombreux exemples de widgets illustrant le modèle de développement. 

Puisque le back-end et le front-end sont découplés, vous devrez héberger deux applications : une pour le back-end et une pour le front-end. Ce type de séparation des préoccupations permet une plus grande évolutivité et des itérations plus rapides au niveau du front-end.

Nous prenons en charge la dernière version, .NET 6, et nous avons l'intention de suivre le cycle de mise à jour du framework.

.NET Core suit les derniers modèles de programmation et nous permet de fournir des fonctionnalités assez rapidement - le développement de nouveaux widgets en est un excellent exemple. Le moteur de rendu .NET Core n'est pas couplé à une vieille pile technologique et stimulera la productivité de vos développeurs. Parallèlement, il permet aux éditeurs de contenu de créer des pages et des formulaires WYSIWYG complets.

Nous vous recommandons vivement d'évaluer soigneusement .NET Core et ses fonctionnalités, car il présente de nombreuses capacités supérieures à MVC. De cette façon, vous serez en mesure de prendre une décision éclairée sur la technologie qui correspond le mieux à vos besoins. Bien que le nombre total de widgets OOB pour MVC soit plus élevé à première vue, de nombreux widgets de . NET Core sont regroupés (par exemple, ContentList vs les widgets autonomes News et Blogs).  En outre, grâce aux nouveaux concepteurs de widgets, vous pouvez créer rapidement des widgets personnalisés.

Oui, il est parfaitement possible d'utiliser vos pages MVC existantes avec .NET Core. Dans ce cas, le moteur de rendu .NET Core agira comme un proxy et présentera les pages MVC au client, ce qui vous permettra d'avoir des pages MVC et .NET Core dans le même projet sans aucun problème. Cette approche est particulièrement utile lorsque vous essayez de faire migrer des projets existants vers .NET Core. 

Quant au mixage de différents types de widgets, vous ne pouvez pas placer vos widgets MVC ou WebForms existants sur une page ou un modèle .NET Core. Seuls les widgets .NET Core peuvent figurer sur les pages .NET Core. Gardez à l'esprit que les paradigmes de MVC et de ViewComponents sont suffisamment similaires pour que certains codes puissent être réutilisés.

Les widgets sont libres et disponibles sur GitHub. Vous pouvez les personnaliser et les étendre pour les adapter à votre cas d'utilisation spécifique.

Le moteur de rendu .NET Core ne vous limite pas à travailler uniquement avec des pages .NET Core. En utilisant le moteur de rendu, vous pouvez travailler simultanément avec des pages .NET Core et MVC et maintenir des sites Web avec une collection mixte de solutions de rendu. De cette façon, vous pouvez migrer votre site Web actuel page par page. 

Pour plus d'informations, reportez-vous à la section Migrer les pages vers .NET Core. Nous vous invitons également à consulter la documentation complète relative au produit Sitefinity .NET Core Renderer.