Fermer

juin 30, 2022

Pourquoi migrer votre solution Sitecore Headless


En tant que développeur .NET Sitecore, je ne peux pas dire que j’étais enthousiasmé par cela… Dans une vie antérieure, j’étais développeur front-end, mais c’était il y a si longtemps que cela ne s’est peut-être jamais produit. Cependant, au fur et à mesure que je brosse les toiles d’araignées de mon «ancien» et que j’apprends cette nouvelle technologie, je suis à 100% d’accord avec ce changement et je vais vous expliquer pourquoi.

1.) C’est Vite. Comme super rapide.

En tant que développeurs back-end, nous avons tendance à oublier l’expérience de l’utilisateur final. Vous vous souvenez de l’époque où les temps de chargement étaient importants ? Au fur et à mesure que les vitesses de connexion sont devenues rapides, les charges utiles sont devenues énormes et nous passons moins de temps à optimiser la livraison car la différence entre 1 et 2 secondes n’a rien d’extraordinaire. Cependant, il existe un ÉNORME différence entre <.5 et 1 seconde. Il semble être instantané. Cliquez sur pouf c’est là. Que se passe-t-il lorsque c’est la norme de l’industrie ? Vous ne pouvez pas le faire avec la configuration traditionnelle du CD et les allers-retours vers votre serveur SQL avec des charges utiles modernes. C’est trop lent.

Sitecore - Comprendre les approches de développement : une perspective de Sitecore

Alors, comment faites-vous alors? Facile, il vous suffit de pré-rendre l’intégralité de votre site Web sous forme de fichiers statiques et de le mettre en cache. S’il existe un contenu dynamique, vous le récupérez à partir d’un service de périphérie de réseau distribué dans le monde entier. Avec l’ampleur du contenu que nous avons l’habitude de servir dans un environnement Sitecore, cela devient rapidement un problème d’ingénierie compliqué. Comment faites-vous les mises à jour, le contenu dynamique, la localisation, la personnalisation, etc… Heureusement, il existe des outils pour vous aider notamment Suivant.js, Vercel et L’expérience de Sitecore.

2.) C’est totalement Modulaire mec…

L’un des nouveaux produits les plus excitants que Sitecore lancera cette année est l’offre SaaS Sitecore XM Cloud. Fini le temps des mises à jour vertigineuses de Sitecore et les mises à jour automatisées sont enfin arrivées. Il existe cependant un assez gros compromis de la nouvelle architecture SaaS – il ne prendra pas en charge .NET MVC. Je vais faire une pause pendant une minute pendant que vous déterminez par vous-même ce qui signifie que pour utiliser Sitecore XM Cloud, vous devrez d’abord convertir votre site en architecture sans tête.

J’essaie d’éviter le « DXP composable» mot à la mode ici mais je vais continuer à répéter « DXP composable » dans ce paragraphe car le marketing aime l’optimisation SEO. Mais mis à part le bingo à la mode, « DXP composable » dans l’espace Sitecore est là pour rester et si vous voulez un « DXP composable » vraiment flexible utilisant la plate-forme d’expérience numérique Sitecore™, vous aurez besoin d’un frontal « DXP composable » qui est bien « Composable »…

3.) C’est Évolutif.

Cette configuration est conçue pour le cloud et les réseaux de diffusion de contenu localisés dans le monde entier. Étant donné que nous réduisons le nombre d’allers-retours vers la base de données et le pré-rendu du contenu statique, la livraison à grande échelle devient un jeu d’enfant. Bord de l’expérience Sitecore est un réseau de diffusion de contenu intégré à CloudFlare qui distribuera votre contenu Sitecore sur n’importe quelle plate-forme dans n’importe quelle région à grande échelle sur n’importe quelle plate-forme. Avec une configuration sans tête utilisant Next.js, Vercel et Sitecore Experience Edge, vous vous demandez peut-être pourquoi ai-je même besoin d’un serveur de diffusion de contenu?






Source link