Interface frontale découplée de Drupal
Drupal peut être configuré pour fournir des points d'extrémité REST personnalisés qui peuvent également authentifier les utilisateurs pour fournir des résultats curatés à une interface utilisateur frontale découplée, telle que ReactJS ou VueJS. Cela donne au front-end beaucoup plus de flexibilité dans la conception et la personnalisation, puisqu'il n'est plus lié aux contraintes de Drupal en matière de régions, de blocs, de vues et de thèmes. L'installation de Drupal en mode headless vous donne beaucoup plus de liberté dans la conception et l'implémentation de votre interface.
Drupal continuera à fournir sa présentation par défaut pour la modération du contenu, de sorte que vous n'aurez qu'à construire pour ce avec quoi l'utilisateur final interagira. Vous n'aurez pas à reconstruire la partie administration, qui reste exposée aux utilisateurs autorisés à modérer le contenu.
Applications mobiles et consommation par des tiers
La mise en place d'un Drupal sans tête permet à votre CMS de fournir ses données à de multiples sources, y compris les applications mobiles. Cela signifie qu'il n'y a plus de contenu "dupliqué" à travers les environnements et les systèmes. Créez-le une fois dans Drupal et consommez-le partout immédiatement. Lorsqu'il doit être mis à jour, il suffit de le faire à un seul endroit, et il est également disponible partout immédiatement.
Cette approche ne s'applique pas seulement aux applications mobiles. Si vous avez des clients qui consomment régulièrement vos données, cette approche peut rationaliser le processus. Des autorisations peuvent être définies dans Drupal pour permettre à un sous-ensemble d'utilisateurs d'accéder à un type de contenu spécifique, et filtrer jusqu'au niveau du nœud individuel, si nécessaire. Vous pouvez fournir n'importe quel sous-ensemble de données à un tiers ou à une application en fonction des rôles des utilisateurs et des informations d'identification qui leur sont attribuées.
Intelligence économique
L'intelligence économique est très importante lorsqu'il s'agit de déterminer quel contenu les utilisateurs trouvent utile, lequel fournira un retour sur investissement, et bien d'autres mesures utiles. Le découplage de Drupal permet deux facteurs clés pour aider à la collecte de données de BI.
Des points de terminaison spécifiques peuvent être configurés pour collecter des données à partir du front-end, telles que la consommation basée sur l'utilisateur, l'appréciation, la mise en favori, la mise en signet, les évaluations et bien d'autres mesures.
Un autre ensemble de points d'extrémité peut être configuré pour fournir les données collectées à un ETL ou à un autre demandeur en vue de leur intégration dans des lacs de données ou d'autres modèles de BI.
Cela signifie qu'il n'est plus nécessaire d'écrire des requêtes personnalisées sur les bases de données à partir de votre ETL. Il n'est plus nécessaire de maintenir de grandes procédures stockées dans votre base de données Drupal. Il suffit de configurer votre ETL ou votre modèle de BI pour extraire des données d'un point de terminaison REST et les utiliser comme vous le souhaitez, laissant à votre plateforme de BI le soin de faire le travail le plus important, à savoir transformer ces données en métriques communicables.
Quel est l'intérêt ?
Si vous gérez, conservez et diffusez déjà des données via Drupal, l'intégration de la fonctionnalité REST Content Builder est une intégration relativement simple qui ne nécessite aucun type de migration de données et qui peut être réalisée parallèlement à la fonctionnalité existante sans la toucher ni la modifier. Au fur et à mesure que les fonctionnalités sont déplacées vers un nouveau front-end unifié, votre empreinte Drupal peut être réduite en supprimant plusieurs éléments de complexité de Drupal qui conduisent l'expérience front-end, y compris :
Vues
Affichages des vues d'entités
Thèmes personnalisés et contributifs, y compris les pré-processeurs complexes et les modèles TWIG
Les modules personnalisés et contributifs qui gèrent, insèrent ou manipulent des bibliothèques et des fonctionnalités frontales.
Cette question devient plus complexe si vous n'utilisez pas Drupal et dépend de votre volonté de créer un nouvel endroit pour le contenu ou de migrer le contenu existant d'un autre système vers Drupal et de le servir à partir de cet endroit. Le passage à Drupal peut être particulièrement avantageux pour une organisation dont le contenu est réparti entre plusieurs CMS, car il permet de disposer d'une seule source de vérité et d'un seul endroit pour la modération et la curation du contenu, ce qui réduit les frais généraux liés à la gestion du contenu.
Sécurité
Le découplage de Drupal du front-end offre un niveau de sécurité supplémentaire au contenu fourni par Drupal.
Obfuscation
Avec Drupal sans tête, l'utilisateur final ne sait probablement pas de quel type de système proviennent les données, puisqu'il ne voit que la technologie frontale. Il ne saura pas non plus où se trouvent ces données, puisqu'elles seront probablement stockées sur un serveur sécurisé derrière un VPN auquel on ne peut accéder qu'à partir d'applications figurant sur une liste blanche au sein d'un réseau. Même si un acteur malveillant parvenait à identifier le point d'accès demandé, il ne saurait toujours pas sur quoi repose ce système, ce qui le rend plus difficile à attaquer et à pénétrer.
Permissions granulaires sur le contenu
Dans Drupal, les rôles et les autorisations peuvent être modérés au niveau de l'organisation ou même au niveau de l'utilisateur, puis ces autorisations sont définies sur le contenu ou les types de contenu. Par exemple, si vous êtes une organisation B2B qui sert plusieurs entreprises, vous pouvez avoir du contenu qui n'est accessible qu'à des clients spécifiques. Des rôles et des autorisations peuvent être définis et appliqués à des utilisateurs spécifiques associés à chaque organisation, puis Drupal vérifiera en interne les autorisations du contenu avant de le diffuser. Vous pouvez même aller plus loin et donner à certains membres d'une organisation spécifique plus ou moins d'accès que le reste de l'organisation, avec des permissions et des rôles supplémentaires. Tout cela est possible grâce à la transmission d'une clé API spécifique à l'utilisateur dans l'en-tête de la requête.
Réponses d'erreur personnalisées
Dans de nombreux cas, des fuites de données peuvent se produire lorsque des points de terminaison sont demandés avec des paramètres, des en-têtes, etc. incorrects. La mise en place d'un constructeur de contenu REST personnalisé permet d'attraper toutes les erreurs et, dans le pire des cas, de renvoyer simplement un message d'erreur générique sans divulguer d'informations sensibles au mauvais acteur potentiel, y compris les systèmes d'exploitation, les informations sur l'utilisateur ou le contenu, ou même le fait qu'il est servi par Drupal.
Conclusion
Faire de votre CMS Drupal une partie précieuse et intégrée de votre framework MVC distribué n'est peut-être pas aussi simple que d'appuyer sur un interrupteur, mais c'est bien plus facile que de gérer à long terme des données à travers de multiples sous-systèmes et c'est hautement préférable aux expériences frontales par défaut de Drupal lorsqu'il s'agit de personnalisation. Si l'on considère qu'il est possible d'ajouter des consommateurs à l'infini, il n'y a plus de limites. Prêt à commencer ou à poursuivre votre voyage dans Drupal avec Improving ? N'hésitez pas à nous contacter.
