Gatsby: construyendo apps siguiendo Jamstack
Ricardo Vega / 23 noviembre 2020
⏰ 12 minutos
Ricardo Vega / 23 noviembre 2020
⏰ 12 minutos
En el anterior post, hablábamos de JAMstack y Jamstack donde ya te introducía que editedmi siguiente entrada sería sobre Gatsby que, además de ser uno de los principales referentes dentro de los frameworks Jamstack, es la herramienta que empleo en este blog desde mediados de 2020 sustituyendo a Pelican que a su vez había sustituido a Wordpress.
Si no has leído mi anterior artículo, creo que es recomendable que empieces por él antes de abordar este ya que lo referenciaré en varias ocasiones y en gran parte podemos considerar que esta entrada es una continuación de dicho artículo.
En primer lugar, Gatsby es un framework para construir aplicaciones Jamstack y, por tanto genera, partiendo de una serie de contenido, todo un juego de ficheros estáticos que deberemos subir a nuestro servidor web o CDN para servirlo.
Todas las características, beneficios y desventajas que veíamos en Jamstack, están presentes en él pero, por no repetirme, voy a centrarme en las más importantes:
Gatsby está basado en React y por tanto en Javascript. Esto hace que podamos usar de forma directa gran número de componentes y librerías dentro de nuestra web hecha con Gatsby lo cual es una gran ventaja si tenemos en cuenta el enorme ecosistema que ya tiene React de por sí.
Además, hace que montar una web con Gatsby sea muy sencillo si ya conoces React, quien por otra parte cada vez es más popular dentro del desarrollo web.
A parte de React en sí, emplea JSX y MDX (Markdown + JSX) lo que nos da una enorme potencia para construir plantillas y páginas específicas.
Veremos más adelante que Gatsby intenta hacer especial foco en el rendimiento desde el punto de vista del usuario lo que se traduce entre otras cosas en reducir los tiempos de carga y renderizado.
Para ello siguen el patrón PRPL que, de forma abreviada, se resume en:
Si quieres profundizar en el tema, creo que este post puede ayudarte a ello. 😃
Esta técnica es empleada por Gatsby pero podríamos decir que es una funcionalidad de React que nos permite "re-hidratar" el contenido de una web generada con React en el servidor (SSR), con Javascript en cliente para dotarle de un extra en cuanto a interactividad.
Existen excelentes artículos sobre esta técnica como:
pero por sintetizarlo un poco para que tengamos una noción general, React, al igual que otros frameworks SPA y aún estando centrados en el renderizado en cliente, permiten ser renderizados en el servidor para atajar algunos de los problemas que presentan estas arquitecturas como el deficiente SEO o el elevado tiempo de carga inicial. Sin embargo, y aunque en el servidor se genere el HTML, cuando ya están pintados en el servidor, se lanza un proceso que es transparente al usuario y que reemplaza sin que nos demos cuenta el HTML del servidor por componentes React renderizados en el cliente. No es un re-renderizado sino más bien es como si se conectase el HTML generado en el servidor y entregado al navegador con el ciclo de vida de una SPA para que a partir de este momento, pueda continuar funcionando como SPA (con las ventajas a nivel de interactividad que esto implica) siempre que el navegador soporte Javascript (si no es así no ocurre nada y sigue funcionando de forma tradicional lo que sortea problemas con el SEO).
Ya hintroduje GraphQL en un post anterior por lo que no me voy a detener en explicar qué es para no alargar más este artículo. Lo que si creo que merece una explicación es su uso dentro de Gatsby:
Gatsby desacopla el contenido de la vista. Este es un concepto fundamental de la filosofía de Gatsby. Pues bien, la forma que tiene de dotar de datos a los componentes y páginas de la vista es a través de queries con GraphQL. Por detrás, el contenido podrá estar en una API externa, en Markdown dentro del propio proyecto o en cualquier otro repositorio de información, pero de cara a la vista, hay un único punto de información que es GraphQL. Esto hace posible el desacople que a su vez permite que la vista crezca y sea reutilizable sin pensar qué motor de información tiene detrás.
Los diferentes proveedores de información son plugins del sistema, pudiendo usar alguno de los ya hechos o creando el tuyo propio para adaptarlo a tus necesidades.
Esta decisión de usar GraphQL, añade algo de complejidad a Gatsby pero flexibiliza mucho su manejo por lo que creo que los "pros" compensan los "contras".
Hasta ahora, hemos visto las principales características de Gatsby, pero estas no dejan de ser un reflejo de cómo intenta la herramienta resolver aquellos puntos que considera más importantes:
Puedes leer sobre ello en "SEO with Gatsby" pero podríamos decir que Gatsby quiere que construir una app "SEO friendly" sea sencillo, sin necesidad de que tu te preocupes por ello de forma directa.
El resultado es aplicaciones interactivas con toda la potencia de React pero perfectamente entendibles por los crawlers de los buscadores, que posicionan de forma correcta y donde incluso podemos tomar el control usando React Helmet de los metadatos que servirán para describir la aplicación no sólo a Google o Bing, sino también a Redes Sociales como Twitter, Facebook o Linkedin.
Esta característica, veíamos que es un punto concreto de la filosofía Jamstack y en Gatsby está muy presente con una excelente documentación, una metodología de trabajo bastante abierta y mediante el uso de herramientas modernas de desarrollo, ya presentes en el ecosistema React, pero perfectamente integradas dentro de Gatsby para facilitar el desarrollo de aplicaciones como Webpack.
El tiempo de carga de una web es crítico y se calcula que cada 100 ms adicionales, baja un 1% los beneficios de la web si estamos hablando de e-commerces.
Además, y aunque muchas veces pensamos en nuestros usuarios sentados delante de un navegador y conectados a través de su red de alta velocidad, la realidad es que muchas veces se encuentran detrás de móviles, tal vez de hace un par de años, y con redes saturadas y/o lentas que dificultan la navegación.
Tradicionalmente, las SPAs tienen problemas serios en este aspecto al necesitar descargar mucha información antes de ser interactivas. Sin embargo, paradójicamente, cada vez hay más SPAs debido a la buena interactividad que presentan una vez cargadas. Gatsby no es una SPA pero trae los beneficios de esta arquitectura sin el sacrificio de los tiempos de carga gracias al patrón PRPL que ya hemos explicado antes.
He querido separar este punto aparte puesto creo que se puede considerar una ventaja, pero también es algo que se ha buscado activamente en el desarrollo. Gatsby presenta un diseño muy modular con dos "anexos" posibles totalmente diferenciados:
A mayores, existe el término de "starters" que no son otra cosa que generadores de aplicaciones pre-definidas con algunas decisiones ya tomadas. Los "starters" se emplean como punto de partida (de ahí su nombre) para construir aplicaciones en Gatsby sobre una base con unos temas y plugins ya seleccionados. A mayores, los starters puede darnos hechos componentes específicos que se usen dentro de la aplicación así como configuraciones.
Plugins, temas y starters son los puntos centrales sobre los que se cimenta (y crece) el ecosistema de Gatsby puesto que, si bien existen elementos de estos tipos con la categoría de "oficiales" (lo cual no significa otra cosa que han sido desarrollados por el core de Gatsby), cualquier persona puede publicar y compartir los suyos propios.
Esta apertura y flexibilidad ha ayudado a que, sobre la base ya existente de Gatsby liderada por la organización que centraliza su desarrollo, haya crecido un ecosistema muy potente y una comunidad muy comprometida que no hace más que retroalimentarse.
Aquí tendría cabida hablar de nuevo de la experiencia de desarrollo y cómo un producto como Gatsby donde dicha experiencia está tan presente, invita a desarrolladores a unirse que a su vez mejoran el producto, lo que invita a nuevos usuarios y se genera un círculo virtuoso con la comunidad en el centro. Pero si expando cada una de estas ideas, me va a salir un post infinito. Me lo dejo para otro post 😉.
Sus principales desventajas, son compartidas con el resto de generadores estáticos o aplicaciones Jamstack:
Bueno, es una buena pregunta... Creo que para responderla racionalmente, podemos centrarnos principalmente en sus desventajas y que son comunes a otras generadores Jamstack:
Estos dos puntos, dan casos de usos claros donde sí parece que usar Jamstack en general y por tanto Gatsby en particular, se una buena idea como pueden ser blogs, portfolios o "landing pages". También hay casos donde casi todo el contenido es dinámico y además es muy cuantioso así que podemos afirmar que Jamstack y Gatsby son una mala idea. Sin embargo, existen muchos grises entre medio que creo que hay que evaluar de forma detallada. Como comentaba en mi artículo genérico de Jamstack, existen múltiples casos de e-commerce (con una mezcla de contenido estático y dinámico) que han resultado éxitos de implementación de Jamstack. No me quiero repetir, por lo que creo que si aún no has leído ese artículo, concretamente sus conclusiones, lo hagas ahora para intentar tener una idea más clara de mi opinión al respecto.
Suponiendo que Jamstack encaje en nuestra idea de proyecto, creo que Gatsby es una fantástica opción (por algo es la que empleo en este blog). Sobre todo si estás acostumbrado a usar Javascript o en particular React, verás que te resulta fácil montar una aplicación de forma sencilla y con un gran potencial de personalización para adaptarlo exactamente a sus necesidades. También creo que puede ser una buena opción si no tienes este conocimiento pero quieres adquirirlo.
Gatsby en particular creo que destaca frente a otros generadores Jamstack en ecosistema (muchas cosas ya las ha hecho alguien y puedes reutilizarlas), flexibilidad (su forma de gestionar el contenido facilita usar prácticamente la fuente de datos que quieras) y en pequeños detalles de rendimiento (por ejemplo, se nota que existe un esfuerzo por mejorar el tiempo de carga de la app sin sacrificar su interactividad pero también se intenta minimizar alguno de los problemas conocidos como el tiempo de compilación mediante estrategias de cacheo de compilados).
Si me preguntas sobre si estoy contento personalmente con su uso te diría un rotundo sí pero igualmente te diría que si odias Javascript y/o React, definitivamente creo que debes buscar una alternativa distinta.
Me alegro que hayas llegado hasta aquí. Espero que con estos dos artículos haya quedado un poco más claro qué es Jamstack y cómo es uno de los frameworks más empleados dentro de este stack como es Gatsby.
Un saludo,
Ricardo