Actualización: desde entonces he creado una versión más reciente de este proyecto utilizando Vue en lugar de React. En las próximas semanas, a través de una serie de artículos, explicaré cómo estoy utilizando Node.js y Express en el backend con un servidor GraphQL conectado a una base de datos MYSQL de WordPress que utiliza Apollo para obtener datos y canalizarlos a los componentes de React. No te preocupes, seguiré utilizando la interfaz de administración de WordPress probada y verdadera.

Si eso suena como un bocado, es porque lo es. Ha sido un reto, sobre todo porque es mi primera incursión en GraphQL y Apollo. Las cosas van a cambiar. El cambio es bueno.

Este post explicará por qué.

WordPress es un gigante. El 25% de los sitios web están construidos sobre WordPress. Es un gran CMS, con una gran comunidad, y un gran soporte. Gestionar el contenido es fácil y ese es el objetivo principal de cualquier CMS.

En nclud desarrollo sitios de WordPress a diario. Administrar sitios de WordPress es un placer. Desarrollarlos no lo es. Lo digo como desarrollador de Javascript que ha experimentado cómo son las aplicaciones isomórficas de Javascript. Javascript me tiene twitterpated. El desarrollo de WordPress no.

¿Qué puedo decir? No me gusta el PHP. No me gustan las plantillas. No me gusta «el bucle». Me he echado a perder con Node, Express, Webpack, React, Babel, y ahora Graph QL y Apollo.

Los beneficios de Javascript

Vengo a esto puramente desde el lado del desarrollo front-end. Node y Express son impresionantes, pero la principal fuerza impulsora detrás de esta configuración, para mí, es la capacidad de utilizar ES2015 con React y CSS-Modules.

El mayor desafío de desarrollar y mantener cualquier sitio web o aplicación de tamaño decente es la capacidad de manejar con gracia los cambios (añadiendo nuevas características o modificando las existentes) sin romper cosas. Esto normalmente implica asegurarse de que la aplicación o modificación de estilos no tenga consecuencias no deseadas. Esto es un reto si se tiene en cuenta que CSS tiene un alcance global. Hay metodologías CSS enteras que fueron creadas para facilitar este dolor (SMACSS, BEM, etc.) pero o bien implican convenciones de nomenclatura esotéricas, o requieren que recuerdes un billón de nombres de clases diferentes.

Con React, podemos usar Módulos CSS para crear CSS de alcance local. Cada componente tiene su propio estilo, que la capacidad de componer clases CSS para otros estilos, o un conjunto de estilos globales. Es muy potente. Tampoco es posible con WordPress.

También puedes hacer estilos en línea, usar JSXStyles o una miríada de otras soluciones – soy un fanático de los Módulos CSS así que eso es lo que usaré.

Este método también significa que los componentes de React son fácilmente intercambiables entre proyectos. Son reutilizables, enchufables. Debido a que los estilos están localmente asignados a un componente, se puede añadir y eliminar a voluntad sin tener que preocuparse de romper algo más.

Otro beneficio es la capacidad de manejar el estado de la aplicación o del sitio web de una manera mucho más elegante. Usando Apollo (del que hablaré en otro post) podemos gestionar no sólo los datos de la aplicación, sino el estado de la UI. Demasiadas veces en WordPress veo un gran archivo javascript que maneja eventos e interacciones para todo un sitio web. Demasiadas veces veo en ese largo archivo pruebas para ver si un elemento tiene una clase que debería desencadenar una animación. Esto lleva a una depuración dolorosa porque el estado de la aplicación no es consistente.

Por último, ahora también podemos realizar pruebas unitarias. ¡Las pruebas son importantes! Huzzah testing!

¿No está ya WordPress haciendo cosas de Node?

Si has estado siguiendo las noticias de WordPress, probablemente habrás oído que Automattic, la compañía detrás de WordPress, ha desarrollado una interfaz de administración construida sobre Node. Es bastante dulce, y ha sido de código abierto. Es impulsado por la API REST de WordPress, por lo que puede obtener todas sus cosas de WordPress en JSON y hacer magia con él.

Eso es bastante bueno.

Cuando me propuse originalmente para tratar de reemplazar PHP con Javascript, mi primer pensamiento fue usar esta API. Tiene algunos buenos puntos finales incorporados, y tienes la posibilidad de crear los tuyos propios. La documentación de la V2 es un poco escasa, pero lo atribuyo a que es tan nueva.

No estaba muy contento con el resultado, aunque admito que sólo jugué con él durante un día o así. Además, como ya estoy usando React, también podría abrazar todo el ecosistema.

Entra GraphQL

¿No sería genial que la UI de nuestra aplicación o sitio web pudiera manejar los datos que necesita? Con REST, el servidor envía todos los datos que la UI podría necesitar, y luego deja que el cliente clasifique el resto. Es posible que tenga que hacer llamadas a múltiples puntos finales de REST para obtener todos los datos posibles.

Con GraphQL, el cliente determina las relaciones de datos que necesita y hace una consulta para obtenerlos todos. Sólo hay un viaje. Y obtienes exactamente lo que necesitas.

De todas formas, puedes leer más sobre GraphQL vs. Rest aquí.

Siguientes pasos

En mi próximo post, recorreré la configuración básica de Node.js/Express y cómo configurar el servidor GraphQL básico. También voy a caminar a través de cómo estoy usando Webpack para manejar Módulos CSS con SASS, cómo funciona el reemplazo de módulos en caliente. También usaré Sequelize para crear una conexión a una base de datos MYSQL de WordPress, lo que significa que no tendremos que escribir UNA SOLA LÍNEA DE CONSULTAS SQL.

Mientras tanto, tengo un repo de Github que contiene donde estoy actualmente en este proceso. Tiene algunas consultas básicas de Post y Postmeta y algunas otras cosas interesantes. Obviamente está en desarrollo activo, y estoy seguro de que hay algunos errores embarazosos en allí, así que siéntase libre de burlarse.