Cas d'utilisation et leurs avantages

À propos de l'auteur

Aaron Hans rend les applications Web rapides et accessibles à tous les utilisateurs. Diriger l’équipe responsable de la réponse publique à la pandémie de l’État de Californie…
En savoir plus sur
Aaron
↬

En repensant aux années de développement pour le Web, j'ai utilisé des dizaines de Outils CMS à la fois sur étagère et homebrewed. J'ai déployé et créé de nombreux sites et plugins WordPress ainsi que des extensions pour des sites CMS à service complet dans .NET. Mais pour moi, tout a changé quand j'ai entendu parler pour la première fois de sans tête, et maintenant, des années plus tard, je ne pourrais pas me sentir plus à l'aise dans l'écosystème sans tête .

Cet enthousiasme ne vient de nulle part . Bien qu'il puisse sembler intimidant de donner un sens à toutes les options sans tête, j'ai affiné ma propre stratégie pour différentes options sans tête dans différents environnements, et je me suis familiarisé étroitement avec les suspects habituels dans l'espace sans tête. Le passage au headless m'a aidé à éviter de rencontrer des obstacles causés par les limitations des plus grands systèmes tout-en-un.

La fonctionnalité de compartimentage pour que vous puissiez atteindre des objectifs complexes aujourd'hui et préparer votre application à évoluer facilement dans le futur apporte moi la tranquillité d'esprit. Ce fut un plaisir de contribuer à des déploiements et itérations réussis sur des services Web basés sur des solutions sans tête pour les entreprises privées et le gouvernement de l'État de Californie.

Dans cet article, je serais ravi de partager quelques-uns des conseils et directives utiles que j'ai appris tout au long de ces années, dans l'espoir qu'ils vous aideront à comprendre le monde sans tête et à trouver les bons candidats pour vos projets. Mais avant de plonger, nous devons remonter un peu le temps pour comprendre ce que le headless apporte à la table.

Before Headless

Il y a quelques années à peine, nos flux de travail semblaient se concentrer sur une gamme d'outils , piles et technologies. Pour CMS, nous utilisions principalement des outils tout-en-un. Ils incluaient à la fois les fonctions de création de contenu et de visualisation de contenu.

Les utilisateurs de ces outils étaient bloqués avec le frontal fourni avec le backend. Votre capacité à personnaliser les choses était limitée. Vous pouvez installer des plugins, mais ils doivent tous être conçus pour votre outil. Vous pouvez écrire du code personnalisé – mais uniquement dans la langue sur laquelle votre outil est construit et dans les limites de ses contraintes.

Tout a changé au cours des dernières années avec le headless CMS qui gagne du terrain dans toute l'industrie. [19659015] Une renaissance des outils spécialisés

Aujourd'hui, nous avons une floraison d'outils qui se spécialisent dans les vues de création ou de présentation de contenu. Un CMS sans tête se concentre sur l'élément de création de contenu et fournit un moyen de connecter un outil de présentation de contenu distinct. L'absence d'un frontend face à l'utilisateur est ce qui le rend sans tête et lui donne la flexibilité de travailler avec n'importe quel outil via son API.

Être capable de concevoir votre propre frontend à partir de zéro est libérateur pour de nombreuses équipes de développement. Vous pouvez avoir une équipe d'ingénieurs capables de fournir des applications d'une seule page lisses dans Vue.js ou des sites générés statiques à rendu rapide et à l'épreuve des balles avec 11ty. Tous les derniers frameworks de développement Web sont conçus pour fonctionner facilement avec des données structurées qui peuvent être fournies à partir de n'importe quel CMS headless.

Un CMS headless est un outil ciblé. Elle a moins de responsabilité qu'une solution tout-en-un. Les points de terminaison d'API fournis par un CMS headless fournissent une séparation nette entre les systèmes afin que vous puissiez échanger les architectures frontales ou backend indépendamment à mesure que les choses évoluent. Votre produit grandit, l'écosystème d'outils se développe, de nouvelles approches deviennent disponibles. Vos exigences en matière de backend et frontend vont changer. Si vous avez une configuration sans tête, vous serez en mesure de vous adapter plus facilement parce que votre front et votre backend sont déjà clairement séparés par une API et vous pouvez les mettre à niveau indépendamment.

Est-ce que Headless me convient?

Plus particulièrement, headless donne vous la flexibilité dont vous pourriez avoir besoin pour répondre à des exigences exigeantes. Il peut être difficile d'atteindre vos objectifs si vous devez modifier fortement un produit tout-en-un. Combiner un outil headless avec une interface plus petite, différente ou homebrewed peut être le moyen le plus simple de fournir les conceptions et les flux d'utilisateurs souhaités.

• Si vous souhaitez affiner chaque étape du processus de paiement du produit vous pouvez utiliser une option de commerce sans tête pour y parvenir,
• Si vous voulez fortement optimizex pour Time to First Byte vous pouvez utiliser un générateur de site statique qui reconstruit le contenu sur la base d'un headless API CMS,
• Si vous hébergez vos propres outils et que vous êtes prudent en matière de sécurité, vous souhaiterez peut-être verrouiller votre environnement de création derrière le pare-feu et l'utiliser sans tête à partir d'une interface plus simple basée sur Jamstack, [19659022] Si vous diffusez le même contenu à divers clients, tels que le Web, des applications natives ou des widgets tiers, vous pouvez les créer de manière à ce qu'ils communiquent tous sans tête via le même CMS.

Si vous pouvez répondre aux exigences de votre projet ents parfaitement avec un outil tout-en-un, alors les options sans tête sont probablement un peu exagérées pour vous. De la même manière, si votre équipe est parfaitement satisfaite et familiarisée avec votre solution tout-en-un actuelle, vous n'avez pas vraiment à vous soucier de la division des outils avant et arrière. Cependant, si à la place, vous rencontrez les limites de vos outils, alors le headless vous permettra de traiter directement vos points faibles.

Exemple: commerce électronique sans tête

Regardons un choix spécifique sans tête: vous pouvez intégrer un plate-forme de commerce électronique existante, telle que Shopify, en tant que flux complet qui prend en charge l'ensemble du processus de paiement, ou vous pouvez également utiliser une option sans tête fournie par Shopify.

• Dans le premier cas, votre conception reposera fortement sur celle de Shopify modèles et fonctionnalités prêtes à l'emploi donc l'ajustement du flux de paiement sera possible, mais assez limité.
• Dans ce dernier cas, vous pouvez concevoir votre flux de paiement comme vous le souhaitez, et vous vont compter sur Shopify pour effectuer simplement la transaction financière.

La différence significative est que l'option headless va vous obliger à construire chaque vue que votre utilisateur voit. Encore une fois, si cela semble être un problème sans avantage, alors vous n’avez probablement pas besoin d’une solution sans tête.

Une équipe qui a besoin de la version sans tête appréciera la liberté qu’elle offre. Votre conception n'aura aucune contrainte et vous pourrez contrôler chaque pixel de chaque vue. Vous aurez le contrôle total de tout le code s'exécutant sur les appareils de vos utilisateurs, de sorte que vous pourrez suivre, optimiser et accélérer littéralement chaque interaction.

En même temps, vous quittez toujours le traitement des transactions jusqu'à votre solution de commerce électronique sans tête, vous bénéficiez ainsi des avantages de leur système backend.

Le résultat final est: si vous êtes aux prises avec les goulots d'étranglement de votre solution de commerce électronique actuelle, que ce soit Interface utilisateur lourde, interface utilisateur complexe ou simplement inaccessible – alors une option sans tête facilitera la résolution de ces problèmes pour votre équipe. De même, s'il semble que cela permettra à votre équipe d'augmenter plus facilement votre entonnoir de conversion en rendant le déploiement de nouvelles fonctionnalités plus rapide et plus fluide, alors c'est une bonne idée d'envisager également l'option sans tête.

Avoding Lock-In Avec une plate-forme unique

En examinant l'état actuel du front-end, découpler vos véhicules de création et de diffusion de contenu est le moyen le plus sûr de créer des architectures dans un monde où les options pour les outils frontaux et backend sont en constante expansion . Il n'est pas rare que les environnements de création et de lecture aient des ensembles d'exigences différents, donc le fait de pouvoir choisir des outils qui les traitent séparément vous donne de meilleures options pour les deux côtés.

Les configurations basées sur Jamstack sont activées par les API ils sont donc souvent liés à un CMS sans tête. Faire un choix sans tête ne nécessite cependant pas une interface Jamstack . Bien sûr, vous pouvez toujours exécuter du code côté serveur si vous le souhaitez.

Par exemple, j'ai aidé à créer quelques sites exécutant Node.js et Express utilisant des API back-end comme Wordnik.com ] et ce modèle populaire fonctionne sans problème. Le fait d'avoir accès à vos données via des API permet d'abandonner votre code côté serveur en production, de sorte que vous pouvez facilement adopter des approches côté client comme Jamstack si cela a du sens dans votre projet.

Le problème avec les solutions «tout-en-un», c'est que chacune d'elles contient de nombreux engagements . Par exemple, vous devez vous engager à prendre en charge une base de données et un environnement de programmation ou choisir parmi des fournisseurs SaaS qui le font; aussi, vos modifications de conception devront se produire dans les thèmes et plugins disponibles.

Avec headless, nous nous évitons d'être enfermés dans une plate-forme unique. Donc, si vous devez utiliser un nouveau framework frontal pour votre site Web, ou si vous souhaitez supprimer une infrastructure de production coûteuse et utiliser des générateurs de site statiques, ou peut-être souhaitez changer votre CMS sans reconstruire tout votre front-end à partir de zéro – par rapport aux alternatives, vous pouvez réaliser tout cela avec beaucoup moins de friction lorsque vous utilisez une option sans tête. Imaginez que votre organisation propose une nouvelle initiative et un nouveau design, et que les flux soient créés à partir de zéro pour répondre aux nouveaux besoins des utilisateurs. Soudainement, une nouvelle pile technologique doit être assemblée pour répondre à ces exigences.

Le choix d'une option sans tête améliorera la longévité de vos produits et facilitera grandement le transfert de votre contenu vers plusieurs canaux de diffusion en douceur.

Dans de tels cas, vous devrez rechercher une solution prête à l'emploi parfaite qui correspond parfaitement à vos besoins, ou compromettre certaines des exigences de conception et de flux d'utilisateurs pour qu'elle fonctionne suffisamment bien. Mais si vos exigences en matière de conception ou de performances sont strictes, il peut être plus facile d’atteindre ces objectifs en optant pour le sans-tête.

En fin de compte, il existe de nombreux cas d’utilisation lorsque vous choisissez une option sans tête qui donnera à vos produits un une meilleure prise en charge de la longévité tout en facilitant considérablement le transfert de votre contenu vers plusieurs canaux de diffusion en douceur. Être capable de consommer votre contenu sous forme de données structurées lui permet de prospérer sur votre propre site Web, dans vos applications natives, et d'être syndiqué vers des sources externes.

Tout ne doit pas être sans tête

Il se peut que le sans tête soit toujours mieux option, mais ce n’est pas le cas. Si, dans votre projet actuel, vous n'êtes pas trop préoccupé par la conception et les options techniques décrites ci-dessus, ou si vous avez simplement besoin d'un site Web opérationnel qui fait le travail aujourd'hui, vous n'aurez probablement pas besoin de beaucoup de tête sans tête.

Bien sûr, la rapidité de la conception à la livraison est importante, donc comme vous êtes à quelques clics d'un site Web d'apparence décente sans assistance technique appropriée de votre côté, vous voudrez peut-être reporter les options sans tête à une date ultérieure. Vous pouvez vous concentrer sur l'optimisation et la longévité du site une fois que vous avez l'impression que votre idée pourrait fonctionner.

Comment les choix sans tête vous aident à vous remettre des faux pas

Mise à niveau du backend

Les risques liés à la tarification par utilisateur

Il y a quelque temps, J'ai aidé à mettre en place un système de blogs qui serait utilisé par des dizaines d'auteurs. Nous avons été très impressionnés par l'ensemble des fonctionnalités de l'un des fournisseurs de CMS headless, nous l'avons choisi pour le CMS headless et avons apprécié la création d'une interface qui s'intègre parfaitement à notre suite de produits. Finalement, la société a décidé que le nombre d'auteurs devrait être porté à quelques milliers.

Les solutions CMS les plus hébergées ne publient pas la structure de prix pour un nombre d'utilisateurs aussi élevé. Lorsque nous nous sommes renseignés sur le coût de continuer à l'exécuter sur la même plate-forme, nous n'avons pas tout à fait aimé la réponse. Pour que ce système continue à avoir un sens commercial, nous avons dû remplacer notre CMS. Nous avons pu faire le swap sans abandonner le frontend aussi en raison de l'architecture sans tête.

Throttling API

Tant de startups se concentrant uniquement sur l'environnement de création sont capables de créer de beaux produits avec des API conviviales pour les développeurs. Airtable est un exemple d'innovation de feuille de calcul grâce à une interface utilisateur conviviale combinée à une expérience de développeur propre via une API bien documentée.

J'ai construit des prototypes utiles où j'ai introduit des données grattées dans Airtable où elles ont été modifiées par des experts humains, puis j'ai utilisé leur API pour alimenter les vues de contenu s'exécutant sur le site principal et dans les intégrations s'exécutant sur des sites tiers. Lors de la configuration du système read j'ai intégré les données Airtable dans un système prêt pour la production qui pouvait gérer des charges de trafic importantes et cela a bien fonctionné pendant un certain temps.

J'ai commencé à courir. dans des problèmes d'écriture de données cependant. Les appels échouaient en raison de la limite stricte de 5 demandes par seconde. Atteindre cette limite donne un verrouillage complet de la demande d'API de 30 secondes. J'essayais d'envoyer des données à partir d'un système distribué alors j'ai ajouté des manettes et divisé les choses en bases séparées. J'ai pu résoudre ce problème en intégrant des fonctionnalités d'édition de données rudimentaires dans un système basé sur l'instance AWS DynamoDB qui avait lu à partir de la table aérienne. Nous avons pu rapidement échanger les fonctionnalités de l'interface utilisateur de création Airtable pour une plus grande échelle et des factures SaaS mensuelles plus basses.

Ceci est un autre exemple de la façon dont une séparation nette entre le frontend et le backend fournie par les API de les outils de création sans tête vous permettent de cibler précisément les points faibles.

Mise à niveau du frontend

Nouveaux cadres brillants

Les organisations qui existent depuis un certain temps ont souvent le problème de devoir prendre en charge des systèmes de production basés sur une variété des piles technologiques . Il y a une pression constante pour homogénéiser l'outillage mais aussi pour innover. Je faisais partie d'une équipe chargée de créer des vues et des widgets qui s'intégreraient dans des produits existants basés sur un CMS headless. Nous nous sommes beaucoup amusés à construire rapidement des prototypes avec différents outils frontaux légers.

Nous avons organisé un concours interne pour voir quel ingénieur de l'équipe frontend pouvait créer le meilleur frontend en fonction du contenu fourni par les points de terminaison de l'API CMS sans tête. Une présentation avait le meilleur ensemble de fonctionnalités et la plus petite empreinte de code, de sorte que les développeurs ont obtenu le projet et livré le produit en le construisant avec Riot.js .

Riot.js est un petite bibliothèque cool qui contient une tonne de fonctionnalités dans une petite taille. Il vous aide à écrire des composants de fichier unique basés sur les données tels que Vue.js. Lorsque le développeur de cette interface a quitté l'entreprise peu de temps après la livraison de la version 1.0, l'équipe a perdu la seule personne enthousiaste pour cette bibliothèque.

Parfois, la chute d'un modèle de développement passionnant, nouveau et rapide à la dette technologique se produit rapidement.

Heureusement , la nature découplée de l'architecture CMS sans tête offre la flexibilité de changer votre frontend sans toucher au backend . Nous avons pu réécrire le code frontal et échanger des composants frontaux mis à jour basés sur différentes bibliothèques qui étaient plus couramment utilisées sur d'autres projets.

Raw Speed ​​

J'adore le projet Ghost . J'étais un des premiers abonnés car c'était cool de voir une solution de type WordPress construite sur Node.js. Je respecte cette organisation pour offrir un service basé sur des outils open source qu'ils affinent constamment. J'étais vraiment satisfait de cet outil lorsque je l'ai utilisé pour mon blog personnel.

Il y avait une facette de la solution qui n'était pas parfaite cependant. Le Time to First Byte sur mon blog hébergé par Ghost était trop lent. Comme je pouvais récupérer tout le contenu de l'article via une API, j'ai pu configurer mon propre frontend généré statiquement sur S3 + Cloudfront qui utilisait tout le contenu de l'article que j'avais écrit dans Ghost mais avait un temps plus rapide pour le premier octet.

Headless CMS en tant que service

Il existe de nombreuses entreprises de logiciel en tant que service qui sont all-in all-in sur headless. L'inscription à l'un de ces fournisseurs peut immédiatement vous offrir un environnement d'édition de contenu convivial et nettoyer les points de terminaison d'API avec lesquels travailler. Voici une comparaison rapide de quelques-uns d'entre eux qui ont tous des plans d'entrée de gamme à très faible coût et un focus laser sur l'expérience de CMS sans tête.

Tous ces services ont un ensemble de de base solide de fonctionnalités . Ils incluent tous l'hébergement d'actifs statiques, l'historique des révisions enregistré et une prise en charge de localisation bien documentée. Ils diffèrent par leur interface utilisateur de création de contenu et leurs fonctionnalités API.

Motifs sans tête passionnants

Utilisation d'un CMS basé sur GitHub

Pouvoir tirer parti des flux de travail de gestion des utilisateurs, de contrôle de version et d'approbation dans GitHub sont de gros avantages. Il est utile de ne pas avoir à ouvrir de nouveaux comptes sur de nouveaux systèmes. Être capable de voir l'historique des révisions parallèlement aux mises à jour du contenu, c'est bien.

Il existe différentes versions des outils CMS basés sur GitHub. Celui-ci a été un moyen rapide de créer des sites de documentation: Spacebook vous pouvez l'intégrer à Netlify pour obtenir une interface utilisateur d'édition de démarque plus propre ou l'utiliser directement sur GitHub.

Les fonctionnalités d'aperçu qui sont maintenant intégrés à l'éditeur Web GitHub rendent certains de ces outils plus accessibles aux personnes qui ne sont pas familiarisées avec le HTML. J'adore l'option de comparaison riche en affichage où GitHub affiche les changements de démarque en mode aperçu complet.

Il s'agit d'une excellente liste de 85 outils CMS qui vous permet de trier selon s'ils sont basés sur GitHub ou non .

API pour les outils familiers

Votre installation WordPress est fournie avec des points de terminaison d'API, vous pouvez donc continuer à utiliser les outils de création que votre équipe a expérimentés de manière illimitée. WordPress a une belle documentation pour leur API REST. Ceci est activé sur les nouvelles installations WordPress, donc lorsque vous lancez un nouvel environnement de création WordPress, vous pouvez commencer à lire JSON à partir de https://example.com/wp-json/wp/v2/posts .

] La page des paramètres de WordPress contient un champ de service de mise à jour dans lequel vous pouvez saisir les URL des services auxquels vous souhaitez envoyer un ping lorsque le contenu change. C'est parfait pour déclencher un outil sans serveur pour récupérer les dernières mises à jour. WordPress v5 a ce champ dans la section Écriture des paramètres

Combinaison de sources de données

L'utilisation d'outils sans tête pour l'état de Californie nous a aidés à créer des sites d'intervention d'urgence qui ont élevé la barre des performances. Nous avions le contrôle total de l'architecture frontale et étions toujours en mesure de laisser les rédacteurs utiliser des outils de création familiers.

Nous utilisons WordPress sans tête écrivant sur GitHub via FAAS. Nous écrivons également d'autres sources de données dans le référentiel et déclenchons le générateur de site statique à chaque modification. Des exemples de données écrites sur git en plus du contenu éditorial original sont des données qui ne changent qu'une fois par jour, comme les statistiques du dessus et nos versions traduites par l'homme de chaque page.

Utilisation des actions GitHub comme déclencheurs de construction nous a permis d'intégrer plusieurs sources de données différentes dans le site afin d'obtenir une publication rapide et une faible empreinte d'infrastructure de production. Moins d'infrastructure de production nous permet de respirer facilement lorsque nous rencontrons de gros pics de trafic liés aux annonces de pandémie du gouvernement.

La partie repo WordPress -> FAAS -> GitHub de l'architecture a été créée par Carter Medlin. Il a câblé ce pipeline à partir de zéro en quelques jours pendant que nous concevions et construisions l'interface du site. Cela s'exécute sur une fonction MS Azure sans serveur, de sorte que les coûts d'infrastructure et la maintenance sont faibles. Il obtient des pings du service de mise à jour WordPress décrit précédemment, extrait json de l'API WordPress et écrit un nouveau contenu dans GitHub. Le code de ce point de terminaison sans serveur est consultable sur GitHub .

Nos robots travaillent dur publiant toutes les mises à jour de contenu lorsqu'ils reçoivent des pings de WordPress. Cette activité crée un journal facilement révisable de chaque mise à jour et la possibilité d'annuler les modifications avec les processus GitHub habituels.

Construire l'interface de ce site à l'aide du 11ty static Le générateur de site était rapide, amusant et fonctionnait parfaitement. Nous avons de gros pics de trafic sur les actualités liées à la pandémie et le fait de savoir que nous avons une interface statique réduit les risques lorsque le nombre d'utilisateurs simultanés commence à augmenter et nous publions de nombreuses mises à jour de contenu.

J'aime la façon dont la communauté 11ty se concentre. sur les performances et l'accessibilité avec ses classements communautaires et son architecture légère. Il est important de s'assurer que les outils construits par l'État fonctionnent pour tous les Californiens. Nous voulons que les choses fonctionnent sur tout appareil dans des conditions de faible bande passante et supportent tous les technologies d'assistance. C'est plutôt cool que nous puissions utiliser des outils comme 11ty qui facilitent la livraison de sites rapides et accessibles. Nous utilisons des composants Web sur le frontend pour fournir des fonctionnalités supplémentaires tout en gardant le poids du code petit.

Considérations pour faire des choix sans tête

Vous êtes enthousiasmé par les capacités que les outils sans tête offrent à votre équipe? Le nombre d'options disponibles peut être écrasant. Voici une liste de fonctionnalités qui peuvent vous aider à réduire les options:

Fonctionnalités de l'environnement de création

• Facilité de création de documents
• Facilité d'ajout de données structurées
• Options de mise en page
• Aperçu des fonctionnalités
• Flux de travail d'approbation de contenu

Fonctionnalités de l'API de contenu

• Quelles requêtes sont disponibles
• Comment granulaire est la structure du contenu
• Y a-t-il des limitations accès aux données (limites strictes de l'API REST Airtable)
• Évolutivité : avez-vous besoin de placer un CDN devant votre API de contenu
• Facilité d'ajout de localisation
• Sortie de votre contenu, et si vous modifiez vos plans, à quel point l'extraction de toutes vos données sera-t-elle difficile?

Coût

• Êtes-vous payant par utilisateur pour des solutions hébergées?
• Gérez-vous des logiciels open source que vous installez dans votre propre environnement?
• Les comptes d'utilisateurs sont-ils faciles à administrer? [19659022] Pouvez-vous intégrer vos solutions d'authentification unique existantes?
• Le produit a-t-il réussi des audits de sécurité, inclut-il l'authentification à deux facteurs ?

Flux de contrôle / approbation de la source

• Est contenu versionné afin que vous puissiez revenir aux versions précédentes et garder une trace de ce qui a été publié et quelles modifications ont été apportées quand?
• Pouvez-vous partager de nouvelles versions du contenu avant la publication leur? Pouvez-vous restreindre l'accès à ces aperçus?

Gestion des fichiers statiques

• Est-il facile pour vos auteurs d'ajouter de nouvelles images, fichiers PDF, etc.? ] Où se dirige le sans tête

  Lorsque vous regardez de près le paysage sans tête, vous découvrirez que les outils sans tête limitent intentionnellement leur portée fonctionnelle et fournissent des moyens de s'intégrer dans des systèmes plus grands. Le dégroupage des fonctionnalités spécifiques est bénéfique lorsque les systèmes deviennent plus complexes. Il est simplement plus facile de faire des choix spécifiques qui limitent le coût, la sécurité, la maintenance et les exigences d'hébergement des empreintes de code plus importantes lorsque vous travaillez avec des outils plus petits et ciblés.

  Il convient de noter que les options sans tête nécessitent généralement d'écrire du code ] toi même. Cependant, comme les frontaux sont de plus en plus un ensemble de composants pré-construits et souvent une conception prête à l'emploi complète remplie de vos propres données, il ne devrait pas être trop présomptueux de s'attendre à plus de façons de mélanger et d'associer des outils spécialisés et d'intégrer de manière transparente options headless sans écrire vous-même le code.

  Le backend parfait pour un projet pourrait être juste un abonnement SAAS ou une installation de projet open-source. Cela peut s'intégrer sans code à une interface prête à l'emploi qui répond à tous vos besoins. Je vois que Stackbit fusionne déjà les CMS sans tête avec leur interface sans code. Je peux configurer un nouveau site en utilisant l'outil de création de page de code WYSIWYG de Stackbit, puis je peux choisir parmi un ensemble d'options de CMS sans tête de différents fournisseurs pour gérer toutes les données du site.

  Dans cet article, nous avons passé en revue certaines des cas d'utilisation où le sans tête a aidé les entreprises pour lesquelles j'ai travaillé à faire face au changement. Les choix sans tête sont attrayants que vous soyez intéressé par la flexibilité de l'architecture des applications, le contrôle de l'expérience utilisateur ou une réflexion approfondie sur la longévité de votre service.

  Je suis ravi de voir comment cet espace continue de croître et va continuer à chercher des moyens d'utiliser ces options pour fournir de meilleurs produits et faciliter mon travail de développeur.

  Autres ressources

  (vf, il)