Escalando WordPress con Next.js

¡Hola a todos! Vamos a hablar sobre WordPress y cómo podemos escalarlo con Next.js. Entonces, ¿quién soy yo? Soy Colby Fayok. Soy el que abraza a BB8 y Kylo Ren allí. Trabajo con la comunidad de desarrollo como defensor del desarrollador para Appletools. Puedes encontrarme prácticamente en cualquier lugar de la web buscando mi nombre en Google, ya que soy el único en el mundo.

Comencemos abordando el CMS en la habitación. Es 2021, y algunos desarrolladores se estremecerían ante la idea de WordPress. Pero francamente, todavía vivimos en un mundo de WordPress. Según Build with Trends, si observamos la distribución de CMS de los 1 millón principales sitios, el 40% de los sitios web están utilizando WordPress. No estoy seguro de cuán precisa es esta cifra, pero si observas el número de detecciones en el sitio de Built with, hay más de 800 millones de instalaciones de WordPress. Esa es una cifra asombrosa. Si bien es posible que no todos queramos usar WordPress, es realista que se quede para el futuro previsible. Entonces, hablemos de cómo podemos aprovechar el CMS Rey y usarlo para alimentar nuestros sitios Jamstack estáticos en 2021.

Entonces, para comenzar, ¿qué significa Headless en realidad? Con nuestra pila tradicional, alguien visita una página en el navegador. El navegador se conecta al servidor. El servidor realiza todo el trabajo, como solicitar datos de nuestra base de datos, donde luego devuelve el HTML de la página y devuelve una respuesta. Y si tenemos suerte, devolverá esa caché. Finalmente, el navegador muestra esa respuesta a la persona que visita el sitio. Con un enfoque Headless, esa solicitud al servidor es asíncrona en el cliente. En este ejemplo en particular, la persona visitaría una página en el navegador e inmediatamente recibiría una respuesta directamente desde el almacenamiento. Una vez que esa página se carga en el navegador, el navegador iniciará otra solicitud a un servidor, que puede cargar todo el contenido dinámico. Pero me imagino que te preguntarás, ¿por qué querríamos hacer una solicitud del lado del cliente a un CMS como WordPress? Y esa no es necesariamente la forma recomendada, ahí es donde entran en juego los generadores de sitios estáticos para hacer el trabajo pesado antes de que tu página esté en el navegador, lo que ha dado lugar a lo que la gente ahora llama el Jamstack.

Tal vez hayas oído hablar del Jamstack en Twitter, o tal vez sea completamente nuevo, pero ¿qué es exactamente? En el núcleo, los sitios Jamstack son sitios web estáticos en HTML. No es una idea nueva, pero es un enfoque moderno. Por lo general, utilizan JavaScript en el navegador para realizar cualquier solicitud a tus APIs que proporcionarían contenido dinámico. O pueden utilizar esas APIs en tiempo de compilación y servir ese contenido dinámico sin una solicitud adicional del lado del cliente. Un ejemplo que podemos imaginar es construir una aplicación React. Esto serviría como nuestro reproductor de JavaScript. Querríamos utilizar la API de WordPress para proporcionar el contenido y los datos dinámicos.

Compilaremos eso en un sitio estático utilizando Next.js u otra herramienta, que, junto con muchas otras características, es un generador de sitios estáticos.

Ahora, si todo esto es nuevo para ti, suena como mucho trabajo. ¿Por qué no usar simplemente WordPress tal como siempre lo hacemos? Lo genial de los sitios JAMstack es que tienen muchas características convincentes incorporadas. Por defecto, estamos cumpliendo con lo que AWS considera una infraestructura bien diseñada. Estas son características que a todos nos importan, como rendimiento, confiabilidad y costo.

Con la mayoría de las soluciones basadas en servidores como WordPress, hay muchas opciones para acelerar las cosas. Para WordPress en particular, eso incluye complementos para caché o algún trabajo personalizado bajo el capó. Pero cada página sigue siendo una solicitud al servidor, lo que está sujeto a altibajos. Por otro lado, servir un archivo HTML plano y estático simplemente será rápido. En lugar de pasar tiempo renderizando en un servidor, sirves un archivo estático directamente desde el almacenamiento o un CDN. Si bien esto se puede hacer con un WordPress predeterminado, a menudo es mucho más complicado. En algunos de los complementos, esa caché puede servir un archivo HTML, pero aún lo sirven desde un servidor regular, no desde el almacenamiento. Con cualquier servidor, generalmente pagamos por la cantidad de tráfico que esperamos. Si bien la mayoría de las veces eso es predecible, todos esperamos que algún día uno de nuestros artículos se vuelva viral. Y si eso sucede, las personas que visitan nuestro sitio serán las que lo paguen con velocidades lentas y tiempos de espera.

Existen soluciones como el equilibrio de carga y la escalabilidad automática, pero no son soluciones perfectas y es posible que no siempre manejen cierto tráfico. Volviendo al hecho de que estamos sirviendo archivos HTML estáticos, porque estamos sirviendo archivos directamente desde el almacenamiento, o mejor aún, archivos estáticos directamente desde un CDN, alerta de palabra de moda, eso significa que nuestro sitio web para el usuario se escalará infinitamente. Ese sitio estático sobrevivirá al abrazo de la muerte de Reddit cuando tu publicación se vuelva viral. Pero administrar servidores no siempre es barato. Si bien un blog personal con poco tráfico puede administrarse con unos pocos dólares al mes, cuanto más crezca ese tráfico, más rápido crecerá ese costo. Si bien tienes opciones nuevamente como el equilibrio de carga y la escalabilidad automática, esos servicios se suman rápidamente y sin ellos, corres el riesgo de que tu sitio se ralentice o, peor aún, tenga tiempo de inactividad. El almacenamiento es realmente, realmente económico. Podemos mantener proyectos estáticos enormes en AWS utilizando S3 a un costo muy bajo. Pero incluso si todavía administramos un servidor, ese uso será mucho, mucho menor con solo administradores de contenido o solicitudes que se realizan en tiempo de compilación.

Aunque hay muchas soluciones o opciones sin cabeza disponibles, es un mundo sin cabeza. WordPress todavía tiene muchas características que lo hacen atractivo para su uso. Un problema con muchas de las soluciones recientes es que parecen estar muy enfocadas en los desarrolladores, y eso no es necesariamente algo malo, pero debes conocer a tu audiencia. Si el objetivo final es que el CMS sea utilizado por personas no técnicas, estás brindando una experiencia que las personas pueden tener dificultades para aprender y usar. WordPress es el CMS más utilizado en la industria. Eso significa que la mayoría de nuestros clientes ya estarán familiarizados con WordPress. Ya existe un ecosistema enorme y próspero en torno a WordPress.

Si te encuentras con un problema, es muy probable que puedas encontrar a alguien que ya haya tenido ese mismo problema con una simple búsqueda en Google. También podemos aprovechar muchas soluciones de la comunidad que extienden WordPress.

Bien, entonces si es tan bueno, veamos cómo se ve realmente. Desde la versión 4.7, WordPress admite de forma predeterminada una API REST. Esto significa que, de hecho, WordPress está disponible como una API sin cabeza desde el principio. Pero yendo un paso más allá, gracias a Jason Ball, quien creó WPGraphQL, que es un complemento que podemos agregar directamente en nuestro panel de WordPress, tenemos la capacidad de consultar nuestros datos de WordPress con GraphQL.

Así que cerrando el círculo completo, podemos aprovechar este enfoque donde aprovechamos las APIs en tiempo de compilación para producir sitios web estáticos. En lugar de esperar una solicitud al servidor, tendremos todo nuestro sitio de WordPress disponible como documentos HTML. Y eso es exactamente lo que he hecho con Next.js, donde he creado un Next.js WordPress Starter, que permite a cualquiera crear fácilmente un nuevo sitio de WordPress estático con el marco de React Next.js. Lo he configurado para que en nuestra página de inicio, cuando estamos compilando el sitio, primero obtengamos el primer conjunto de publicaciones, como comúnmente veríamos en un sitio de blog. Esas se pasan como props a la página que se construye en React, donde luego puedo crear la interfaz de usuario como desee.

Debido a que Next.js no conocerá las rutas de antemano con una ruta dinámica, necesitamos averiguar todas esas páginas que necesita crear. Así que obtenemos todas las publicaciones y luego creamos nuevas rutas para cada una de esas publicaciones, indicando a Next.js que cree una nueva página para cada una. Con todo eso y un poco de pulido, pude compilar estáticamente un sitio de WordPress con Next.js. El objetivo aquí no era hacer que todos se cambien a WordPress, sino mostrar su flexibilidad y por qué sigue siendo una opción convincente junto con las demás. Podemos encontrar soluciones muy poderosas que brindan una gran experiencia de usuario, al mismo tiempo que son eficientes y económicas. Si quieres ver mi trabajo, el inicio de Next.js WordPress es completamente de código abierto en mi GitHub. Y si quieres aprender más sobre el Jamstack, puedes consultar mi libro en jamstackhandbook.com. Y eso es todo. Si quieres aprender más o hablar sobre la charla, puedes encontrarme en todas partes como Colby Fayhawk, mis mensajes directos están abiertos y también tuitearé un enlace con algunas de las cosas que has visto aquí hoy. ¡Gracias a todos!