Comment ajouter des fonctionnalités Headless à votre solution Sitecore MVC ou SXA

Si vous êtes sur Sitecore depuis au moins quelques années, vous avez probablement une solution MVC personnalisée ou vous avez utilisé un accélérateur comme SXA (j’espère que vous n’avez plus de formulaires Web et XSLT maintenant). Cette solution comprend probablement des composants et des intégrations personnalisés. Cette solution a peut-être même survécu à une ou deux mises à niveau. Cette solution a probablement mis des années à se mettre en place. Ainsi, lorsque Sitecore et d’autres fournisseurs de CMS ont commencé à vanter les mérites du futur, le scepticisme était votre réaction naturelle. Recommencer juste au moment où tout fonctionne enfin ne semble pas attrayant.

Dans cet esprit, vous avez peut-être cessé d’écouter lorsque les avantages des solutions sans tête, tels que des temps de chargement plus rapides, une facilité de déploiement, des coûts d’infrastructure réduits et une plus grande flexibilité, ont été vantés par Sitecore et la communauté de développement. Ne pas écouter était une erreur. Une erreur basée sur un faux dilemme. Rester avec votre solution existante et passer au headless ne doit pas être une décision de tout ou rien. Vous pouvez introduire lentement le headless dans votre solution.

Les bases

Lors de l’utilisation des services Headless de Sitecore, le contenu et la mise en page sont gérés dans Sitecore et mis à la disposition des applications utilisant son « service de mise en page ». Cela signifie que le site Web réel n’est pas servi par les CD de Sitecore, mais par un hôte de rendu. Ce sera généralement Node.js ou pourrait être le noyau ASP.Net. Sitecore fournit des SDK qui aident à intégrer le service de mise en page dans votre solution.

Si vous créez un nouveau site Web en utilisant sans tête, vous pouvez simplement mapper le DNS sur votre hôte de rendu et Sitecore uniquement sur le contenu du service et les détails de mise en page à l’aide du service de mise en page. Si vous avez des sites Sitecore existants construits à l’aide de MVC ou SXA, vous pouvez les servir côte à côte, sans conflits puisque l’hôte de rendu ne servira que les demandes à un site sans tête distinct.

Le faire fonctionner sur un seul site

Si vous avez déjà un site, vous souhaiterez peut-être introduire de nouvelles fonctionnalités sans tête sans utiliser de domaine distinct. Cela peut facilement être résolu en utilisant un proxy inverse. Si vous utilisez Azure, Front Door gère cela facilement. Les demandes arrivent à la porte d’entrée et, en fonction du chemin, elles acheminent les demandes soit vers l’hôte de rendu sans tête, soit vers vos CD Sitecore.

Cela vous permet soit d’étendre votre site existant avec des fonctionnalités conçues pour prendre entièrement en charge le headless. C’est également un moyen de déplacer lentement les fonctionnalités existantes vers sans tête sans avoir besoin d’effectuer une reconstruction de gros sac.

Pour cela, vous devrez peut-être dupliquer vos composants d’en-tête et de pied de page, bien qu’ils puissent tous deux être pilotés à partir du même contenu qui prend en charge votre solution MVC/Sitecore existante. Vous devrez peut-être également réfléchir à la manière de prendre en charge le partage des données de session ou de l’état authentifié entre la solution sans tête et le site existant.

Et si vous n’êtes pas sur Sitecore 10 ?

Pour tirer parti des services Headless de Sitecore, vous devez disposer de la dernière version de Sitecore. Mais si votre solution principale se trouve sur une ancienne version de Sitecore et que vous n’êtes pas prêt à effectuer la mise à niveau, vous pouvez toujours utiliser Front Door pour gérer le trafic entre votre instance existante et une nouvelle instance prête à prendre en charge les services headless.

Gardez à l’esprit que vous aurez besoin de plus d’infrastructure et de licences pour prendre en charge cette approche, mais si une mise à niveau est en cours, cela peut vous permettre de progresser plus rapidement avec de nouvelles fonctionnalités parallèlement à la mise à niveau de la solution avec un impact limité sur les licences.

Si cela devient plus une solution à long terme, un domaine que vous devrez peut-être résoudre est de fournir une recherche de site unifiée qui renvoie les résultats des deux instances. Pour ce faire, vous aurez besoin d’un index unifié. Bien que vous puissiez essayer d’avoir une instance de Sitecore indexer l’autre, d’autres solutions comme Covéo ou Apache Nutch qui peuvent indexer les pages rendues sont plus faciles à maintenir.

Le rendre encore plus rapide

Une fois que vous utilisez le headless pour piloter certaines parties de votre site, vous pouvez envisager de le rendre encore plus rapide en tirant parti de l’expérience de Sitecore. Avec cette approche, les détails de votre mise en page et de votre contenu sont publiés sur le CDN Experience edge de Sitecore, assurez-vous que ces détails sont mis en cache au plus près du visiteur.

Avec cette approche, votre application headless est complètement indépendante de votre instance de diffusion de contenu Sitecore. L’ensemble de l’application est servi à partir de votre hôte de rendu et de votre expérience. Vous serez également prêt pour le cloud XM dès sa sortie.

Emballer

Headless offre de réels avantages, et vous n’avez pas besoin d’attendre de pouvoir reconstruire l’intégralité de votre solution pour commencer à récolter ces avantages. Lorsqu’ils sont correctement planifiés, des outils tels que Front Door peuvent faciliter le service de vos fonctionnalités sans tête côte à côte avec les solutions MVC et SXA standard.

Si c’est une voie que vous envisagez d’emprunter, nous serions ravis de vous aider. Contactez-moi sur LinkedIn, Twitter ou remplissez notre formulaire de contact.