Drupal is API-first, not API-only

Drupal est API-First, pas uniquement API

De plus en plus de développeurs choisissent des solutions de content-As-a-service connues sous le nom de blogs sans tête, des référentiels de contenu qui offrent des interfaces éditoriales non-superflues et exposent des API de contenu pour la consommation par un éventail d'applications en expansion.

Les blogs sans tête partagent quelques traits communs: ils manquent des extrémités avant de l'utilisateur final, fournissent peu à aucuns outils éditoriaux pour l'affichage et la disposition, et en tant que tels laissent des soucis de présentation presque entièrement jusqu'au lotisseur de front-end. Décapité blogs ont gagné en popularité parce que:

  • Un désir de séparer les préoccupations de structure et de présentation afin que les équipes frontales et les équipes back-end puissent travailler indépendamment les unes des autres.
  • Les éditeurs et les marketeurs sont à la recherche de solutions qui peuvent servir de contenu à une liste croissante de canaux, y compris les sites Web, les systèmes back-end, les applications monopages, les applications natives, et même les dispositifs émergents tels que portable, interfaces conversationnelles, et les appareils de l'ITO.

En raison de cette tendance chez les développeurs, beaucoup se demandent à juste titre si Blogs sans tête sont le défi du marché pour les blogs traditionnels. Je ne suis pas convaincu que Blogs sans tête comme ils se trouvent aujourd'hui sont là où le monde CMS en général est dirigé. En fait, je crois qu'une vision nuancée est nécessaire.

Dans ce blog, je vais vous expliquer pourquoi Drupal a un avantage crucial qui le propulse au-delà des concurrents émergents sans tête: il peut être un CMS exceptionnel pour les éditeurs qui ont besoin de contrôle sur la présentation de leur contenu et un CMS sans tête riche pour les développeurs construisent des écosystèmes de contenu volumineux dans un seul paquet.

Comme Drupal continue à alimenter les sites Web qui ont longtemps été son pain et le beurre, il est également utilisé de plus en plus pour servir le contenu à d'autres systèmes back-end, des applications de page unique, les applications natives, et même les interfaces de conversation-tout en même temps.

Blogs sans tête sont en laissant éditeurs derrière

headless drupal

Ce diagramme illustre les différences entre un site Web Drupal traditionnel et un CMS sans tête avec différents front ends recevant du contenu.

Certains prétendent que Blogs sans tête remplacera Blogs traditionnels comme Drupal et WordPress quand il s'agit de éditeurs de contenu et de marketing. Je n'en suis pas si sûr.

Où sans tête Blogs Fall Flat se trouve dans les domaines de l'administration en contexte et de l'édition sur place du contenu. Nos efforts extérieurs, en revanche, visent à permettre à un éditeur d'administrer le contenu et la structure de page dans une interface à côté d'un aperçu en direct plutôt que dans une interface qui est complètement séparée de l'expérience utilisateur final. Voici quelques exemples de ce paradigme : glisser des blocs directement dans les régions ou réorganiser les éléments de menu, puis voir ces deux modifications s'appliquer en direct.

Rester informé

Recevez le meilleur contenu sur le futur du marketing, les changements dans le secteur et les avis de nos experts.

Par leur nature, sans tête Blogs manque d'expérience éditoriale à part entière intégré dans les extrémités avant à laquelle ils servent le contenu.

À moins qu'ils exposent une interface d'édition de contenu liée à chaque extrémité frontale, l'administration dans le contexte et l'édition sur place sont impossibles. En d'autres termes, de fournir une expérience éditoriale sur le front end, que front end doit être conscient de cette interface de montage de contenu, d'où la nécessité de couplage.

L'affichage et la manipulation de disposition est un autre domaine qui est la clé pour faire du marketing réussie. L'une des principales caractéristiques de Drupal est la capacité de contrôler où le contenu apparaît dans une structure de mise en page. Les blogs sans tête sont unopiniâtre au sujet des arrangements d'affichage et de disposition. Mais tout comme l'édition sur place et l'administration dans le contexte, les outils éditoriaux qui permettent ce besoin d'être intégré dans le front end qui fait face à l'utilisateur final afin d'être utile.

En outre, les éditeurs et les commerçants sont particulièrement préoccupés par la façon dont le contenu va regarder une fois qu'il est publié. L'accès à un système de prévisualisation de bout en bout facile, en particulier pour le contenu non publié, est essentiel pour les workflows de nombreux éditeurs. Dans le paradigme CMS sans tête, les développeurs doivent sauter à travers des cerceaux assez important pour permettre une prévisualisation transparente, y compris la mise en place d'un nouveau point de terminaison API ou environnement de transit et le déploiement d'une version distincte de leur application qui émet des demandes contre les nouvelles Chemins. En conséquence, je crois que la prévisualisation transparente, sans avoir à taper sur l'épaule d'un développeur, est encore nécessaire.

Des fonctionnalités telles que l'édition sur place, l'administration en contexte, la manipulation de la mise en page et la visualisation transparente mais fidèle sont des éléments essentiels pour une expérience éditoriale optimale pour les créateurs de contenu et les spécialistes du marketing. Pour certains cas d'utilisation, ces inconvénients sont totalement gérables, surtout lorsqu'une application nécessite peu d'interaction éditoriale et est plus axée sur le développeur. Mais pour les éditeurs de contenu, blogs sans tête n'offrent tout simplement pas les boîtes à outils qu'ils sont venus à s'attendre; ils tombent à court où Drupal brille.

Drupal habilite les éditeurs et les développeurs d'applications

headless cms

Ce diagramme illustre les différences entre un site Drupal couplé, mais sans tête, et un CMS sans TETE avec plusieurs extrémités frontales recevant du contenu.

Tout cela ne veut pas dire que décapité n'est pas important. Décapité est important, mais le soutien à la fois sans tête et les approches traditionnelles est l'un des plus grands avantages de Drupal. Après tout, les systèmes de gestion de contenu doivent servir le contenu au-delà des sites Web axés sur l'éditeur pour les applications monopages, les applications natives et même les périphériques émergents tels que les portables, les interfaces conversationnelles et les appareils de l'ITO.

Heureusement, l'initiative API-First continue de travailler activement pour faire progresser les efforts existants et les nouveaux services Web qui rendent l'utilisation de Drupal comme un service de contenu beaucoup plus facile et plus optimal pour les développeurs. Nous travaillons à rendre les développeurs de ces applications plus productifs, que ce soit via des services Web qui offrent une grande expérience de développeur comme JSON API et graphql ou grâce à des outils qui accélère le développement d'applications sans tête comme l'écosystème du Waterwheel.

Pour moi, la clé à emporter de cette discussion est la: Drupal est grand pour les éditeurs et les développeurs . Mais il y a quelques avertissements. Pour les expériences Web qui nécessitent un accent important sur l'éditeur ou l'expérience assembleur, vous devez utiliser un frontal Drupal couplé qui vous donne la possibilité d'éditer et de manipuler le front end sans impliquer un développeur.

Pour les expériences Web où vous n'avez pas besoin d'éditeurs pour être impliqués, Drupal est toujours idéal. Dans une approche API-First, Drupal fournit d'autres expériences numériques qu'elle ne peut pas explicitement prendre en charge (celles qui ne sont pas basées sur le Web). Cela vous permet de garder les deux options ouvertes.

Drupal pour votre site, Drupal sans tête pour vos applications

api first

Ce diagramme illustre l'architecture idéale pour Drupal, qui devrait être exploitée à la fois comme une extrémité frontale en soi ainsi qu'un service de contenu pour d'autres extrémités frontales.

En ce jour et l'âge, avoir toutes les chaînes servies par une source unique de la vérité pour le contenu est important. Mais quelle architecture est optimale pour cette approche? Alors que la lecture de ce que vous pourriez avoir également connu un déjà-vu à partir d'un blog que j'ai écrit l'année dernière sur la façon dont vous devriez découpler Drupal, qui est encore des conseils solides près d'un an après que je l'ai posté.

En fin de compte, je recommande une architecture où Drupal est couplée et découplée simultanément; en bref, Drupal brille quand il est positionné à la fois pour les éditeurs et les développeurs d'applications, parce que Drupal est grand dans les deux rôles. En d'autres termes, votre référentiel de contenu devrait également être votre site Web public, un site contigu avec des capacités éditoriales complètes. Dans le même temps, il devrait être la pièce maîtresse de votre collection d'applications, qui ne nécessitent pas d'outils éditoriaux, mais offrent à vos développeurs l'expérience qu'ils veulent. Garder Drupal comme un site couplé, tout en ajoutant simultanément des applications découplées, n'est pas une limitation; C'est une améliora tion.

Conclusion

L'objectif d'aujourd'hui n'est pas de faire de Drupal API uniquement, mais plutôt API-First. Il ne vous limite pas à une approche couplée comme Blogs sans API, et il ne vous limite pas à une approche API uniquement comme content et d'autres blogs décapités. Pour moi, c'est la conclusion la plus importante à tirer de ceci: Drupal soutient un Spectrum de possibilités. Cela vous permet de faire le bon compromis entre l'optimisation pour vos éditeurs et les commerçants, ou pour vos développeurs, et de décaler ailleurs sur ce spectre que vos besoins changent.

C'est un spectre qui englobe les deux extrêmes des scénarios qu'une approche couplée et une approche sans tête représentent. Vous pouvez utiliser Drupal pour alimenter un seul site Web comme nous l'avons depuis de nombreuses années. Dans le même temps, vous pouvez utiliser Drupal pour alimenter une longue liste d'applications au-delà d'un site Web traditionnel. Pour ce faire, Drupal peut être ajusté de haut en bas le long de ce spectre en fonction des exigences de vos développeurs et éditeurs.

En d'autres termes, Drupal est d'abord API, pas uniquement API, et plutôt que de laisser les éditeurs et les commerçants derrière en faveur des développeurs, il donne à chacun ce dont ils ont besoin dans un seul paquet.

Remerciements spéciaux à Preston ainsi pour les contributions à ce billet de blog et à Wim Leers, Ted Bowman, Chris gêner et Matt Grill pour leurs commentaires au cours du processus d'écriture.

Dries Buytaert, chairman and chief technology officer, Acquia

Dries Buytaert

Président, CTO Acquia, Inc.

Dries Buytaert est développeur open source et responsable des technologies. Il est à la fois le fondateur et le chef de projet de Drupal, une plateforme open source dédiée à la création de sites web et d'expériences digitales. Buytaert est également cofondateur et directeur de la technologie d’Acquia, société technologique financée par le capital-risque. Acquia fournit à de nombreuses grandes organisations une plateforme ouverte, basée sur le cloud, qui aide ces dernières à développer, livrer et optimiser leurs expériences digitales. Identifié Young Global Leader par le Forum économique mondial, il est titulaire d’un doctorat en science et ingénierie informatique de l'université de Gand, et d'une licence en science informatique de l'université d'Anvers. Il a été nommé CTO de l'année par le Massachusetts Technology Leadership Council, Entrepreneur de l’année en Nouvelle-Angleterre par Ernst & Young et Jeune Innovateur par la MIT Technology Review. Il écrit souvent des articles de blogs sur Drupal, l'open source, les startups, l'entreprise et l'avenir sous le nom dri.es.