Ir sin cabeza: casos de uso y para qué sirve

Este artículo ha sido amablemente apoyado por nuestros queridos amigos de Storyblok, un CMS sin interfaz amigable con un editor visual, componentes anidados y bloques de contenido personalizables para sitios web y aplicaciones. ¡Gracias!

Mirando hacia atrás en los años de desarrollo para la web, he usado docenas de herramientas CMS diferentes, tanto disponibles como caseras. He estado implementando y creando muchos sitios y complementos de WordPress , así como extensiones para sitios CMS de servicio completo en .NET. Pero para mí, todo cambió cuando escuché por primera vez sobre headless, y ahora, años después, no podría sentirme más cómodo en el ecosistema headless .

Este entusiasmo no surge de la nada. Si bien puede parecer desalentador dar sentido a todas las opciones sin cabeza, he estado refinando mi propia estrategia para diferentes opciones sin cabeza en diferentes entornos, y me familiaricé estrechamente con los sospechosos habituales en el espacio sin cabeza. Pasar a headless me ayudó a evitar los obstáculos causados ​​por las limitaciones de los sistemas todo en uno más grandes.

Compartimentar la funcionalidad para que pueda cumplir objetivos complejos hoy y preparar su aplicación para evolucionar fácilmente en el futuro me da tranquilidad. Ha sido un placer contribuir a implementaciones e iteraciones exitosas en servicios web creados en soluciones autónomas para empresas privadas y el gobierno del estado de California.

En este artículo, me encantaría compartir algunos de los consejos y pautas útiles que he aprendido a lo largo de estos años, con la esperanza de que lo ayuden a comprender el mundo sin cabeza y a encontrar a los candidatos adecuados para sus proyectos. Pero antes de sumergirnos, debemos retroceder un poco en el tiempo para comprender qué trae el headless a la mesa.

antes sin cabeza

Hace solo unos años, nuestros flujos de trabajo parecían centrarse en una variedad de herramientas, pilas y tecnologías. Para CMS, usábamos principalmente herramientas todo en uno. Incluían tanto la creación de contenido como las funciones de visualización de contenido.

Los usuarios de estas herramientas estaban atrapados con el front-end que venía con el backend. Tu capacidad para personalizar las cosas era limitada. Podría instalar complementos, pero todos tenían que construirse para su herramienta. Puede escribir código personalizado, pero solo en el idioma en el que se basa su herramienta y dentro de sus limitaciones.

Todo cambió en los últimos años con CMS sin cabeza ganando terreno en toda la industria.

Un renacimiento de herramientas especializadas

Hoy en día, tenemos un florecimiento de herramientas que se especializan en vistas de creación o presentación de contenido. Un CMS sin encabezado se enfoca en la pieza de creación de contenido y proporciona una forma de conectar una herramienta de presentación de contenido separada. La falta de una interfaz orientada al usuario es lo que lo hace sin cabeza y le da la flexibilidad para trabajar con cualquier herramienta a través de su API.

Ser capaz de diseñar su propia interfaz desde cero es liberador para muchos equipos de desarrollo. Es posible que tenga un equipo de ingenieros de primer nivel con fluidez en la entrega de aplicaciones ingeniosas de una sola página en Vue.js o sitios generados estáticos a prueba de balas de renderizado rápido con 11ty. Todos los marcos de desarrollo web más recientes están diseñados para funcionar fácilmente con datos estructurados que se pueden proporcionar desde cualquier CMS autónomo.

Un CMS sin cabeza es una herramienta enfocada. Tiene menos responsabilidad que una solución todo en uno. Los puntos finales de la API proporcionados por un CMS sin cabeza brindan una separación clara entre los sistemas para que pueda cambiar las arquitecturas de front-end o back-end de forma independiente a medida que evolucionan las cosas. Tu producto crece, el ecosistema de herramientas se expande, nuevos enfoques están disponibles. Sus requisitos de backend y frontend van a cambiar. Si tiene una configuración sin cabeza, podrá adaptarse más fácilmente porque su front-end y back-end ya están claramente separados por una API y puede actualizarlos de forma independiente.

¿Es Headless adecuado para mí?

En particular, headless le brinda la flexibilidad que puede necesitar para cumplir con requisitos desafiantes. Puede ser difícil alcanzar sus objetivos si tiene que modificar mucho un producto todo en uno. La combinación de una herramienta sin cabeza con una interfaz más pequeña, diferente o casera podría ser la forma más fácil de entregar los diseños y flujos de usuario deseados.

• Si desea afinar cada paso del flujo de pago del producto , puede usar una opción de comercio sin cabeza para lograrlo,
• Si desea optimizar en gran medida el tiempo hasta el primer byte , es posible que desee utilizar un generador de sitios estáticos que reconstruye el contenido en función de los cambios en función de una API de CMS sin cabeza,
• Si aloja sus propias herramientas y tiene cuidado con la seguridad, es posible que desee bloquear su entorno de creación detrás del firewall y consumirlo sin cabeza desde una interfaz más simple basada en Jamstack,
• Si está sirviendo el mismo contenido a una variedad de clientes, como web, aplicaciones nativas o widgets de terceros, puede crearlos de manera que todos se comuniquen a través del mismo CMS sin cabeza.

Si puede cumplir con los requisitos de su proyecto sin problemas con una herramienta todo en uno, entonces las opciones sin cabeza probablemente sean un poco exageradas para usted. De la misma manera, si su equipo está perfectamente satisfecho y conoce bien su solución todo en uno actual, realmente no necesita preocuparse por dividir las herramientas de front-end y back-end. Sin embargo, si, en cambio, se encuentra con las limitaciones de sus herramientas, quedarse sin cabeza le permitirá abordar sus puntos débiles directamente.

Ejemplo: comercio electrónico sin cabeza

Veamos una opción autónoma específica: puede integrar una plataforma de comercio electrónico existente, como Shopify, como un flujo completo que se hace cargo de todo el proceso de pago, o puede usar una opción autónoma que también ofrece Shopify.

• En el primer caso, su diseño dependerá en gran medida de las plantillas de Shopify y la funcionalidad lista para usar, por lo que será posible ajustar el flujo de pago, pero bastante limitado.
• En el último caso, puede diseñar su flujo de pago de la forma que desee, y confiará en Shopify para realizar simplemente la transacción financiera.

La diferencia significativa es que la opción sin cabeza requerirá que construyas cada una de las vistas que ve tu usuario. Una vez más, si eso suena como una molestia sin ventajas, entonces probablemente no necesite una solución sin cabeza.

Un equipo que necesite la versión sin cabeza agradecerá la libertad que ofrece. Su diseño no tendrá restricciones y podrá controlar cada píxel de cada vista. Tendrá el control total de todo el código que se ejecuta en los dispositivos de sus usuarios, por lo que puede rastrear, optimizar y acelerar literalmente cada interacción.

Al mismo tiempo, sigue dejando el procesamiento de las transacciones en manos de su solución de comercio electrónico autónoma, por lo que obtiene los beneficios de su sistema de back-end.

La conclusión es: si está luchando con los cuellos de botella dentro de su solución de comercio electrónico actual, ya sea una interfaz de usuario pesada, una interfaz de usuario compleja o simplemente un diseño inaccesible, entonces una opción sin cabeza facilitará que su equipo resuelva estos problemas. Del mismo modo, si parece que le facilitará a su equipo aumentar su embudo de conversión al hacer que la implementación de nuevas funciones sea más rápida y fluida, entonces también es una buena idea considerar la opción sin cabeza.

Evitar el bloqueo con una sola plataforma

Mirando el estado actual del front-end, desacoplar sus vehículos de creación y entrega de contenido es la forma más segura de diseñar cosas en un mundo donde las opciones para herramientas front-end y back-end están en constante expansión. No es raro que los entornos de creación y lectura tengan diferentes conjuntos de requisitos, por lo que poder elegir herramientas que los aborden por separado le brinda mejores opciones para ambos lados.

Las configuraciones basadas en Jamstack están habilitadas por las API, por lo que a menudo están vinculadas a un CMS sin cabeza. Sin embargo, hacer una elección sin cabeza no requiere un front-end de Jamstack . Por supuesto, aún puede ejecutar algún código del lado del servidor si lo desea.

Por ejemplo, he ayudado a crear algunos sitios que ejecutan Node.js y Express que consumen API de back-end como Wordnik.com y este patrón popular funciona sin problemas. Tener acceso a sus datos a través de API hace posible deshacerse de su código del lado del servidor en producción, por lo que puede adoptar fácilmente enfoques del lado del cliente como Jamstack si eso tiene sentido en su proyecto.

El problema con las soluciones "todo en uno" es que cada una de ellas tiene muchos compromisos incorporados. Por ejemplo, debe comprometerse a admitir una base de datos y un entorno de programación o elegir entre proveedores de SaaS que lo hagan; además, los cambios de diseño tendrán que ocurrir dentro de los temas y complementos disponibles.

Con headless, salimos de estar encerrados en una sola plataforma. Entonces, si necesita usar un nuevo marco de front-end para su sitio web, o desea eliminar la costosa infraestructura de producción y usar generadores de sitios estáticos, o tal vez desea cambiar su CMS sin reconstruir todo su front-end desde cero, en comparación con las alternativas , puede lograrlo todo con mucha menos fricción cuando usa una opción sin cabeza.

Echemos un vistazo a un ejemplo simple. Imagine que a su organización se le ocurre una nueva iniciativa y un nuevo diseño, y los flujos se crean desde cero para satisfacer las nuevas necesidades de los usuarios. De repente, es necesario ensamblar una nueva pila de tecnología para cumplir con estos requisitos.

Elegir una opción sin encabezado le dará a sus productos una mejor oportunidad de longevidad y hará que sea mucho más fácil dejar que su contenido se mueva sin problemas a múltiples canales de entrega.

“

En tales casos, deberá buscar una solución lista para usar perfecta que se adapte perfectamente a sus necesidades, o comprometer algunos de los requisitos de flujo de usuario y diseño para que funcione lo suficientemente bien. Pero si sus requisitos de diseño o rendimiento son estrictos, puede ser más fácil cumplir estos objetivos sin cabeza.

La conclusión es que hay muchos casos de uso al elegir una opción sin encabezado que le dará a sus productos una mejor oportunidad de longevidad , así como también hará que sea mucho más fácil dejar que su contenido se mueva en múltiples canales de entrega sin problemas. Poder consumir su contenido como datos estructurados le permite prosperar en su propio sitio web, en sus aplicaciones nativas y sindicarse a fuentes externas.

No todo tiene que ser sin cabeza

Puede sonar que headless es siempre una mejor opción, pero no lo es. Si en su proyecto actual no está demasiado preocupado por el diseño y las opciones técnicas descritas anteriormente, o simplemente necesita un sitio web operativo que haga el trabajo hoy, entonces probablemente no necesite tanto headless.

Por supuesto, la velocidad desde el concepto hasta la entrega es importante, por lo que está a unos pocos clics de un sitio web de aspecto decente sin el soporte de ingeniería adecuado de su lado, es posible que desee posponer las opciones sin cabeza para más adelante. Puede concentrarse en la optimización y longevidad del sitio una vez que sienta que su idea podría estar funcionando.

Cómo las elecciones sin cabeza lo ayudan a recuperarse de los errores

Actualización del back-end

Peligros de los precios por usuario

Hace un tiempo, ayudé a configurar un sistema de blogs que sería utilizado por docenas de autores. Quedamos muy impresionados con el conjunto de funciones de uno de los proveedores de CMS sin cabeza, lo elegimos para el CMS sin cabeza y disfrutamos construyendo una interfaz encima que se fusionó sin problemas con nuestro conjunto de productos. Eventualmente, la compañía decidió que el número de autores debería expandirse a unos pocos miles.

La mayoría de las soluciones de CMS alojadas no publican la estructura de precios para un número de usuarios tan grande. Cuando preguntamos sobre el costo de continuar ejecutando esto en la misma plataforma, no nos gustó mucho la respuesta. Para que este sistema siguiera teniendo sentido comercial, tuvimos que cambiar nuestro CMS. Pudimos hacer el intercambio sin desechar la interfaz también debido a la arquitectura sin cabeza.

Limitación de API

Muchas nuevas empresas que se centran únicamente en el entorno de creación pueden crear productos hermosos con API fáciles de usar para desarrolladores. Airtable es un ejemplo de innovación de hoja de cálculo a través de una interfaz de usuario fácil de usar combinada con una experiencia de desarrollador limpia a través de una API bien documentada.

Creé algunos prototipos útiles en los que alimenté Airtable con datos raspados, donde expertos humanos los editaron, luego usé sus API para potenciar las vistas de contenido que se ejecutan en el sitio principal y en incrustaciones que se ejecutan en sitios de terceros. Al configurar el sistema de lectura , introduje los datos de Airtable en un sistema listo para producción que podía manejar grandes cargas de tráfico y funcionó bien durante un tiempo.

Sin embargo, comencé a tener problemas con la escritura de datos. Las llamadas fallaban debido al límite estricto de 5 solicitudes por segundo. Alcanzar este límite proporciona un bloqueo de solicitud de API completo de 30 segundos. Estaba intentando enviar datos desde un sistema distribuido, así que agregué aceleradores y dividí las cosas en bases separadas.

A medida que el sistema se expandió y la cantidad de datos creció, superamos esta herramienta. Pude abordar esto mediante la creación de funciones de edición de datos rudimentarias en un sistema basado en la instancia de AWS DynamoDB que había estado leyendo desde airtable. Pudimos cambiar rápidamente las ingeniosas características de la interfaz de usuario de creación de Airtable por una escala mayor y facturas mensuales de SaaS más bajas.

Este es otro ejemplo de cómo una separación clara entre el frontend y el backend proporcionada por las API de las herramientas de creación sin cabeza le permite identificar los puntos débiles con precisión.

Actualización de la interfaz

Nuevos marcos brillantes

Las organizaciones que han existido por un tiempo a menudo tienen el problema de necesitar sistemas de producción basados ​​en una variedad de tecnologías . Hay una presión constante para homogeneizar las herramientas, pero también para innovar. Formaba parte de un equipo encargado de crear vistas y widgets que se integrarían en productos existentes basados ​​en un CMS sin cabeza. Nos divertimos mucho construyendo rápidamente prototipos con diferentes herramientas de interfaz livianas.

Realizamos un concurso interno para ver qué ingeniero del equipo de frontend podía crear el mejor frontend en función del contenido entregado desde los extremos de la API de CMS sin cabeza. Una presentación tenía el mejor conjunto de funciones y el espacio de código más pequeño, por lo que los desarrolladores obtuvieron el proyecto y entregaron el producto al desarrollarlo con Riot.js.

Riot.js es una pequeña biblioteca genial que incluye un montón de características en un tamaño pequeño. Le ayuda a escribir componentes de un solo archivo controlados por datos como Vue.js. Cuando el desarrollador de esta interfaz dejó la empresa poco después de enviar la versión 1.0, el equipo perdió a la única persona entusiasmada con esa biblioteca.

A veces, la caída de un patrón de desarrollo emocionante, nuevo y rápido a la deuda tecnológica ocurre rápidamente.

“

Afortunadamente, la naturaleza desacoplada de la arquitectura de CMS sin cabeza brinda la flexibilidad de cambiar su interfaz sin tocar el backend . Pudimos reescribir el código de front-end e intercambiar componentes de front-end actualizados basados ​​en diferentes bibliotecas que se usaban más comúnmente en otros proyectos.

Velocidad bruta

Me encanta el proyecto Ghost. Fui uno de los primeros suscriptores porque fue genial ver una solución similar a WordPress construida en Node.js. Respeto a esta organización por ofrecer un servicio basado en herramientas de código abierto que están refinando constantemente. Estaba muy contento con esta herramienta cuando la usé para mi blog personal.

Sin embargo, había una faceta de la solución que no era perfecta. El tiempo hasta el primer byte en mi blog alojado en Ghost fue demasiado lento. Como podía recuperar todo el contenido de la publicación a través de una API, pude configurar mi propia interfaz generada estáticamente en S3 + Cloudfront que usaba todo el contenido de la publicación que había escrito en Ghost pero tenía un tiempo más rápido para el primer byte.

CMS sin cabeza como servicio

Hay muchas empresas de software como servicio que se han volcado de cabeza. Registrarse con uno de estos proveedores puede brindarle de inmediato un entorno de edición de contenido amigable y puntos finales de API limpios para trabajar. Aquí hay una comparación rápida de algunos de ellos, todos los cuales tienen planes de nivel de entrada de muy bajo costo y un enfoque láser en la experiencia de CMS sin cabeza.

Todos estos servicios tienen un sólido conjunto básico de características . Todos incluyen alojamiento de activos estáticos, historial de revisión guardado y soporte de localización bien documentado. Se diferencian en la interfaz de usuario de creación de contenido y las características de la API.

Emocionantes patrones sin cabeza

Usando un CMS basado en GitHub

Poder aprovechar la gestión de usuarios, el control de versiones y los flujos de trabajo de aprobación en GitHub son grandes ventajas. Es útil no tener que configurar nuevas cuentas en nuevos sistemas. Es bueno poder ver el historial de revisiones junto con las actualizaciones de contenido.

Hay diferentes sabores de herramientas CMS basadas en GitHub. Esta ha sido una forma rápida de activar sitios de documentación: Spacebook puede integrarlo con Netlify para obtener una interfaz de usuario de edición de rebajas más limpia o usarla directamente en GitHub.

Las funciones de vista previa que ahora están integradas en el editor web de GitHub hacen que algunas de estas herramientas sean más accesibles para las personas que no están familiarizadas con HTML. Me encanta la opción de diferenciación rica en vistas en la que GitHub muestra los cambios de descuento en el modo de vista previa completa.

Esta es una excelente lista de 85 herramientas CMS que le permite ordenar si están basadas en GitHub o no.

API para herramientas familiares

Su instalación de WordPress viene con puntos finales de API, por lo que puede continuar usando las herramientas de creación que su equipo tiene experiencia sin supervisión. WordPress tiene buena documentación para su API REST. Esto está habilitado en nuevas instalaciones de WordPress, por lo que cuando inicia un nuevo entorno de creación de WordPress, puede comenzar a leer JSON desde https://example.com/wp-json/wp/v2/posts .

La página de configuración de WordPress contiene un campo de servicio de actualización donde puede ingresar las URL de los servicios a los que desea que haga ping cuando cambie el contenido. Esto es perfecto para activar una herramienta sin servidor para obtener las últimas actualizaciones. WordPress v5 tiene este campo en la sección Escritura de la configuración

Combinar fuentes de datos

El uso de herramientas sin cabeza para el estado de California nos ayudó a crear sitios de respuesta a emergencias que elevaron el nivel de rendimiento. Teníamos el control total de la arquitectura de la interfaz y todavía podíamos dejar que los escritores usaran herramientas de creación familiares.

Usamos WordPress sin cabeza , escribiendo a GitHub a través de FAAS. También estamos escribiendo otras fuentes de datos en el repositorio y desencadenando compilaciones de generadores de sitios estáticos en cada cambio. Ejemplos de datos que se escriben en git además del contenido editorial original son datos que solo cambian una vez al día, como las estadísticas principales y nuestras versiones traducidas por humanos de cada página.

El uso de acciones de GitHub como disparadores de compilación nos permitió integrar varias fuentes de datos diferentes en el sitio para obtener una publicación rápida y una infraestructura de producción pequeña. Menos infraestructura de producción nos permite respirar tranquilos cuando nos enfrentamos a grandes picos de tráfico relacionados con los anuncios de pandemia del gobierno.

La parte del repositorio de WordPress -> FAAS -> GitHub de la arquitectura fue creada por Carter Medlin. Conectó esta tubería desde cero en un par de días mientras diseñábamos y construíamos la interfaz del sitio. Esto se ejecuta en una función MS Azure sin servidor, por lo que los costos de infraestructura y el mantenimiento son bajos. Obtiene pings del servicio de actualización de WordPress descrito anteriormente, extrae json de la API de WordPress y escribe contenido nuevo en GitHub. El código para este punto final sin servidor se puede ver en GitHub.

Nuestros bots trabajan arduamente para publicar todas las actualizaciones de contenido a medida que reciben pings de WordPress. Esta actividad crea un registro fácilmente revisable de cada actualización y la capacidad de revertir los cambios con los procesos habituales de GitHub.

Construir la interfaz de este sitio usando el generador de sitios estáticos 11ty fue rápido, divertido y funcionó perfectamente. Recibimos grandes picos de tráfico en las noticias relacionadas con la pandemia y saber que tenemos una interfaz estática reduce el riesgo cuando el número de usuarios simultáneos comienza a aumentar y publicamos muchas actualizaciones de contenido.

Me gusta cómo la comunidad 11ty se enfoca en el rendimiento y la accesibilidad con sus tablas de clasificación comunitarias y su arquitectura liviana. Es importante asegurarse de que las herramientas creadas por el estado funcionen para todos los californianos. Queremos que las cosas funcionen en cualquier dispositivo en condiciones de bajo ancho de banda y admitan toda la tecnología de asistencia. Es genial que podamos usar herramientas como 11ty que facilitan la entrega de sitios rápidos y accesibles. Usamos componentes web en la interfaz para proporcionar características adicionales mientras mantenemos el peso del código pequeño.

Consideraciones al tomar decisiones sin cabeza

¿Está entusiasmado con las capacidades que las herramientas sin interfaz brindan a su equipo? La cantidad de opciones disponibles puede ser abrumadora. Esta es una lista de características que pueden ayudarlo a reducir las opciones:

Características del entorno de creación

• Facilidad de creación de documentos.
• Facilidad de agregar datos estructurados
• Opciones de diseño
• Funciones de vista previa
• Flujos de trabajo de aprobación de contenido

Características de la API de contenido

• Qué consultas están disponibles
• ¿Qué tan granular es la estructura del contenido?
• ¿Existe alguna limitación en el acceso a los datos (límites rígidos de la API REST de Airtable)?
• Escalabilidad : ¿necesita poner un CDN delante de su API de contenido?
• Facilidad de agregar localización
• Sacar su contenido, ¿qué sucede si cambia sus planes? ¿Qué tan difícil será extraer todos sus datos?

Costo

• ¿ Paga por usuario por las soluciones alojadas?
• ¿Administra software de código abierto que instala en su propio entorno?
• ¿Las cuentas de usuario son fáciles de administrar?
• ¿Puede integrarse con sus soluciones de inicio de sesión único existentes?
• ¿El producto ha pasado auditorías de seguridad, incluye autenticación de dos factores ?

Control de código fuente/Flujos de aprobación

• ¿El contenido está versionado para que pueda retroceder a versiones anteriores y realizar un seguimiento de lo que se publicó y qué ediciones se realizaron y cuándo?
• ¿Puedes compartir nuevas versiones de contenido antes de publicarlas? ¿Puedes restringir el acceso a estas vistas previas?

Gestión de archivos estáticos

• ¿Qué tan fácil es para sus autores agregar nuevas imágenes, archivos PDF, etc.?
• ¿Facilidad para conectar los archivos subidos por el autor a los flujos de optimización de imágenes?

Hacia dónde se dirige sin cabeza

Cuando observa de cerca el panorama sin cabeza, descubrirá que las herramientas sin cabeza limitan intencionalmente su alcance funcional y brindan formas de integrarse en sistemas más grandes. La desagregación de características específicas es beneficiosa cuando los sistemas se vuelven más complejos. Simplemente es más fácil tomar decisiones específicas que limiten el costo, la seguridad, el mantenimiento y los requisitos de alojamiento de las huellas de código más grandes cuando se trabaja con herramientas más pequeñas y enfocadas.

Vale la pena señalar que las opciones sin cabeza generalmente requieren que usted mismo escriba algo de código . Sin embargo, dado que las interfaces son cada vez más un conjunto de componentes prediseñados y, a menudo, un diseño listo para usar completo que se completa con sus propios datos, no debería ser demasiado presuntuoso esperar más formas de mezclar y combinar herramientas especializadas e integrarse sin problemas. opciones sin cabeza sin escribir el código usted mismo.

El backend perfecto para un proyecto podría ser simplemente una suscripción a SAAS o la instalación de un proyecto de código abierto. Esto puede integrarse sin código con una interfaz lista para usar que satisfaga todas sus necesidades. Veo que Stackbit ya está fusionando CMS sin cabeza con su interfaz sin código. Puedo configurar un nuevo sitio usando la herramienta de creación de páginas de códigos WYSIWYG de Stackbit y luego puedo elegir entre un conjunto de opciones de CMS sin encabezado de diferentes proveedores para administrar los datos completos del sitio.

En este artículo, hemos repasado algunos casos de uso en los que quedarse sin cabeza ayudó a las empresas para las que trabajé a sobrellevar el cambio. Las opciones sin cabeza son atractivas , ya sea que esté interesado en ellas por la flexibilidad de la arquitectura de la aplicación, el control de la experiencia del usuario o si piensa detenidamente en la longevidad de su servicio.

Estoy emocionado de ver cómo este espacio continúa creciendo y continuaré buscando formas de usar estas opciones para ofrecer mejores productos y facilitar mi trabajo como desarrollador.

Más recursos

• Headless CMS, una excelente lista de 85 herramientas de CMS que le permite clasificar si están basadas en GitHub o no.
• "Cómo crear un sitio de WordPress sin cabeza en el Jamstack", Sarah Drasner y Geoff Graham
• Comercio sin cabeza, Shopify
• "GoTrue JS: llevar la autenticación a sitios estáticos con solo 3 kb de JS", Divya Sasidharan, Netlify
• La experiencia de edición para sitios Jamstack, Stackbit
• API de integración de Wordpress, CAdotGov, GitHub

Este artículo ha sido amablemente apoyado por nuestros queridos amigos de Storyblok, un CMS sin interfaz amigable con un editor visual, componentes anidados y bloques de contenido personalizables para sitios web y aplicaciones. ¡Gracias!