gatsbyjs.com

¿De qué trata Gatsby?

Gatsby es un framework de React para crear sitios web a partir de componentes y contenido estructurado. Puede recopilar datos de archivos, sistemas de gestión de contenido, APIs y otros servicios; organizar esos datos mediante una capa GraphQL; y utilizarlos para crear páginas con renderizado estático, diferido, del lado del servidor o del lado del cliente.

Gatsby es el framework. gatsbyjs.com es su sitio web oficial y centro de documentación. Esta distinción es importante porque la arquitectura, los paquetes y el repositorio del framework son los temas de esta guía, mientras que el dominio es donde el proyecto publica su documentación.

Un proyecto de Gatsby suele reunir varios aspectos en un solo flujo de trabajo:

• Los componentes de React definen la interfaz y los elementos reutilizables de las páginas.
• Los plugins de origen importan contenido y datos de sistemas locales o remotos.
• Gatsby normaliza los registros obtenidos en forma de nodos dentro de su capa de datos.
• Las consultas GraphQL seleccionan los campos que necesitan las páginas y los componentes.
• Las APIs de páginas y las plantillas convierten los datos en rutas.
• La configuración de renderizado determina cuándo se produce cada página.

Cómo se relaciona Gatsby con React

React proporciona el modelo de componentes de Gatsby. Los desarrolladores componen diseños, navegación, plantillas y funciones interactivas a partir de componentes de React, mientras que Gatsby proporciona el framework circundante para el enrutamiento, la obtención de datos, la creación de páginas, el procesamiento de recursos y la salida de producción.

Por tanto, Gatsby no es un sustituto de React ni una simple biblioteca de componentes. Es un framework de sitios web con convenciones definidas y construido alrededor de React. Los equipos pueden aplicar JSX, composición de componentes, props, estado e interacción del lado del navegador que ya conocen, mientras utilizan APIs específicas de Gatsby para los datos y el renderizado.

Lo que Gatsby añade alrededor de React

Aspecto	React proporciona	Gatsby añade
Interfaz	Componentes y estado	Convenciones de páginas, diseños e integración con el proceso de compilación
Datos	Opciones de obtención de datos en el ámbito de la aplicación	Una capa de datos normalizada y un flujo de trabajo de consultas GraphQL
Rutas	Componentes básicos para una aplicación	Páginas basadas en archivos, creación programática de páginas y rutas exclusivas del cliente
Salida	Interfaces renderizadas en el navegador	Renderizado de páginas estático, diferido y en el momento de la solicitud
Integraciones	Un ecosistema general de JavaScript	Plugins, temas, proyectos iniciales y APIs del ciclo de vida del framework de Gatsby

Esta estructura puede resultar adecuada para un equipo de React que crea un sitio web público con mucho contenido. Puede ser innecesaria cuando un proyecto pequeño tiene pocas integraciones de contenido o cuando sus requisitos corresponden principalmente a una aplicación renderizada en el cliente.

La capa de datos y GraphQL

La capa de datos de Gatsby está diseñada para ofrecer a distintas fuentes de contenido una interfaz de consulta común. Los plugins de origen recuperan registros y crean nodos de Gatsby. A continuación, Gatsby pone esos nodos a disposición mediante un esquema GraphQL que las páginas y los componentes pueden consultar.

Un sitio podría combinar archivos Markdown, imágenes, un sistema de contenido sin interfaz y datos seleccionados de servicios. En lugar de hacer que cada página comprenda el formato de respuesta original de cada fuente, Gatsby puede exponer los registros pertinentes mediante un grafo compartido.

Una ruta de contenido habitual tiene este aspecto:

1. Un archivo, servicio o plataforma de contenido contiene el material original.
2. Un plugin de origen importa ese material durante el proceso de obtención de datos de Gatsby.
3. Gatsby representa los registros importados como nodos y crea un esquema.
4. Las consultas GraphQL solicitan los campos requeridos por una página o un componente.
5. Una plantilla utiliza el resultado de la consulta para producir la página.
6. Gatsby renderiza la página según el modo de renderizado seleccionado.

GraphQL es fundamental para el flujo de trabajo de datos obtenidos de Gatsby, pero no sustituye todos los valores habituales de React. Las props de componentes, el estado local, los eventos del navegador y las solicitudes del lado del cliente pueden seguir existiendo fuera del grafo del proceso de compilación. La pregunta útil es si el esquema compartido de Gatsby simplifica el contenido que debe ensamblarse en las páginas.

La capa de datos también introduce trabajo. Los equipos deben comprender el comportamiento de las fuentes, las relaciones entre nodos, los cambios del esquema y las dependencias de las consultas. Un grafo que unifica varios sistemas puede ser valioso, pero su coste de compilación y carga de mantenimiento deben probarse con contenido representativo en lugar de deducirse a partir de un proyecto inicial.

Plugins de origen y el modelo de extensión más amplio

Los plugins de origen conectan Gatsby con los datos. Pueden leer archivos locales o integrar sistemas y servicios de contenido, y después crear nodos que participan en la capa GraphQL. Esto los diferencia de los plugins que añaden procesamiento, analítica, estilos, compatibilidad con imágenes u otros comportamientos del ciclo de vida.

Gatsby agrupa el trabajo reutilizable en tres formas relacionadas:

• Los plugins añaden una fuente, transformación, integración o capacidad del framework.
• Los temas agrupan configuración y funcionalidad reutilizables de Gatsby que los sitios pueden ampliar.
• Los proyectos iniciales proporcionan un proyecto de partida que los desarrolladores copian y adaptan.

Un proyecto inicial puede acortar la configuración, pero sus dependencias y convenciones pasan a ser responsabilidad del equipo que lo adopta. Un tema puede mantener la coherencia de la funcionalidad entre sitios, pero los equipos deben comprender qué controla. Un plugin puede evitar código de integración personalizado, aunque su compatibilidad y mantenimiento deben evaluarse individualmente.

La existencia de una categoría amplia de plugins no demuestra que un paquete concreto sea compatible con la versión de Gatsby, la fuente de datos o el modelo de despliegue de un equipo. Una evaluación práctica debe identificar los paquetes exactos necesarios, revisar su documentación y la actividad de sus repositorios, y probarlos dentro de la arquitectura propuesta.

Opciones de renderizado en Gatsby

Gatsby comenzó con una fuerte asociación con la generación de sitios estáticos, pero su documentación define ahora varias opciones de renderizado. Estas pueden seleccionarse por página, lo que permite que un artículo público, un archivo grande, una ruta dependiente de la solicitud y un área de aplicación utilicen modelos de producción diferentes.

Opción de renderizado	Cuándo se produce la página	Pregunta adecuada que plantear
Generación de sitios estáticos (SSG)	Durante el proceso de compilación	¿Está disponible antes del despliegue el contenido necesario para la página?
Generación estática diferida (DSG)	Cuando se solicita por primera vez una página diferida	¿Puede excluirse esta página del proceso de compilación inicial y admite el alojamiento DSG de Gatsby?
Renderizado del lado del servidor (SSR)	En el momento de la solicitud, mediante getServerData	¿Requiere la respuesta datos o contexto disponibles en el momento de la solicitud?
Ruta del lado del cliente	En el navegador para una ruta de aplicación	¿Se ha diseñado esta sección deliberadamente como una aplicación y qué está disponible antes de que JavaScript termine?

Páginas estáticas y diferidas

SSG produce HTML y recursos relacionados durante el proceso de compilación. Es una opción natural para contenido cuyas entradas se conocen de antemano. Los archivos generados pueden ser fáciles de distribuir, pero una gran cantidad de páginas, consultas costosas, numerosas fuentes de contenido o un procesamiento intensivo de imágenes pueden aumentar las exigencias de compilación.

DSG pospone determinadas páginas hasta su primera solicitud. Esto puede reducir el número de páginas creadas durante el proceso de compilación inicial, especialmente cuando un sitio tiene una larga cola de contenido solicitado con poca frecuencia. También requiere un entorno de despliegue que implemente el comportamiento de generación diferida de Gatsby; no equivale a subir únicamente archivos estáticos a cualquier alojamiento.

Renderizado en el momento de la solicitud y en el navegador

SSR genera una respuesta en el momento de la solicitud mediante la API getServerData de Gatsby. Puede servir páginas cuya salida depende de información actual disponible en el momento de la solicitud, pero introduce ejecución en el servidor, decisiones de almacenamiento en caché, gestión de fallos y requisitos de infraestructura que una página puramente estática evita.

Las rutas del lado del cliente permiten secciones de aplicación gestionadas en el navegador. Pueden coexistir con páginas públicas generadas, pero los equipos deben examinar los estados de carga, la navegación, la accesibilidad y el contenido disponible antes de que se ejecute el código del lado del cliente. No debe presuponerse la visibilidad pública simplemente porque una ruta del navegador acabe mostrando la información correcta.

Ninguna etiqueta de renderizado garantiza velocidad o visibilidad en buscadores. Los resultados dependen del diseño de la página, JavaScript, los recursos, las fuentes de datos, el almacenamiento en caché, el alojamiento y la calidad de la implementación. Gatsby ofrece a los equipos varias opciones arquitectónicas; no elimina la necesidad de medirlas.

Imágenes y producción de contenido

Las imágenes suelen formar parte de la misma canalización de contenido que el texto y los registros estructurados. Los plugins de Gatsby pueden obtener archivos de imagen, transformarlos y conectar los recursos procesados con las consultas de las páginas. Después, los componentes pueden renderizar los datos de imagen seleccionados como parte de una plantilla de página.

Un flujo de trabajo editorial útil separa responsabilidades:

• Los editores gestionan títulos, contenido principal, metadatos y referencias de imágenes en la fuente elegida.
• Los plugins de origen importan esos registros y los recursos referenciados.
• La capa de datos de Gatsby conecta los nodos de contenido con los datos de imagen necesarios.
• Las consultas solicitan únicamente los campos y las variantes de imagen que necesita una plantilla.
• Los componentes proporcionan pies de foto, texto alternativo, dimensiones y comportamiento de diseño.
• El proceso de compilación de producción verifica que los registros, los recursos y las rutas se resuelvan conjuntamente.

El procesamiento de imágenes puede mejorar la coherencia, pero sigue siendo trabajo de compilación. Los equipos deben probar la cantidad y el tamaño reales de los recursos, confirmar cómo afectan los cambios a las nuevas compilaciones y conservar el texto alternativo significativo de la fuente editorial. Un plugin no puede decidir si una imagen es informativa, decorativa o está descrita adecuadamente.

Dónde puede encajar bien Gatsby

Gatsby resulta especialmente pertinente cuando un proyecto ya utiliza React y necesita reunir contenido de varios sistemas. Su grafo de datos puede proporcionar una capa coherente entre esas fuentes y las plantillas de página que las consumen.

Entre las situaciones habituales que merece la pena evaluar se incluyen:

• Sitios de documentación o editoriales que combinan archivos, imágenes y una plataforma de contenido.
• Sitios de marketing con componentes reutilizables de React y registros de páginas estructurados.
• Proyectos de publicación con varias fuentes que se benefician de una única interfaz de consulta.
• Sitios de Gatsby existentes construidos alrededor de APIs de páginas, GraphQL y plugins consolidados.
• Grandes colecciones de contenido donde determinadas páginas pueden ser candidatas para DSG.
• Sitios que combinan páginas públicas generadas con secciones del lado del cliente o renderizadas en el momento de la solicitud.

Gatsby puede encajar de forma menos directa cuando un proyecto tiene una sola fuente de contenido sencilla, no se beneficia de un grafo normalizado o necesita una arquitectura de aplicación centrada principalmente en operaciones en el momento de la solicitud y del lado del cliente. Se trata de un criterio arquitectónico, no de un veredicto sobre la calidad del framework.

Compensaciones de compilación y despliegue

La generación estática traslada trabajo a antes del despliegue. Gatsby puede necesitar recuperar datos de origen, construir su esquema, ejecutar consultas, crear páginas, procesar imágenes, empaquetar código y escribir la salida. La duración y los requisitos de recursos dependen del proyecto real.

Una evaluación representativa debe registrar:

Área de prueba	Qué verificar
Escala del contenido	Cantidad de páginas, cantidad de nodos, relaciones y tamaños de registros realistas
Fiabilidad de las fuentes	Autenticación, límites de solicitudes, fallos y recuperación repetible
Consultas	Estabilidad del esquema, coste de las consultas y errores tras cambios en el contenido
Imágenes	Volumen de procesamiento, uso de memoria, tamaño de salida y metadatos editoriales
Renderizado	Salida SSG, primeras solicitudes DSG, respuestas SSR y carga de rutas del cliente
Despliegue	Compatibilidad con todos los modos elegidos, comportamiento del almacenamiento en caché y recuperación ante fallos

Una demostración pequeña no puede establecer cómo se comportará un catálogo completo. Los equipos deben probar compilaciones limpias, cambios incrementales cuando sean compatibles, interrupciones de las fuentes de contenido y páginas situadas tanto en los extremos habituales como en los extremos excepcionales del conjunto de datos.

DSG puede trasladar trabajo fuera del proceso de compilación inicial, mientras que SSR traslada trabajo a las solicitudes. Son cambios en el momento de ejecución y en la responsabilidad operativa, no mejoras gratuitas de rendimiento. El alojamiento elegido debe admitir el comportamiento requerido de Gatsby, y el equipo debe comprender qué ocurre durante una solicitud en frío o un fallo de un servicio de origen.

Gatsby, Astro y otras alternativas

Gatsby y Astro pueden aparecer ambos en evaluaciones de sitios web basados en contenido, pero organizan los proyectos de forma diferente. Gatsby sitúa en el centro a React, su capa de datos GraphQL, los plugins de origen y las APIs de generación de páginas. Astro debe evaluarse según su propia arquitectura documentada, en lugar de considerarse de manera predeterminada una respuesta más rápida o más nueva.

Gatsby merece una consideración más detallada cuando un equipo quiere utilizar React en toda la interfaz, necesita consultar varias fuentes de contenido normalizadas, depende de integraciones de Gatsby o mantiene una base de código consolidada de Gatsby. Otro framework puede ser más sencillo cuando ese grafo y el ciclo de vida de los plugins añadirían estructura sin resolver un problema real de contenido.

Una comparación útil crea la misma sección representativa en cada candidato: una fuente de contenido, una página compleja, un listado, gestión de imágenes, navegación y el modo de despliegue previsto. Compare la comprensión de los desarrolladores, el comportamiento del proceso de compilación, la salida en el navegador, la accesibilidad, los requisitos de alojamiento y la responsabilidad del mantenimiento. Evite declarar un ganador universal basándose en plantillas predeterminadas.

Fundador y recursos oficiales de la comunidad

En una sesión oficial de preguntas y respuestas de la comunidad de Gatsby publicada el 2 de abril de 2020, Kyle Mathews fue identificado como “Fundador @ GatsbyJS”. Esa atribución fechada describe su función histórica en esa fuente; no debe interpretarse como una afirmación sobre el liderazgo actual de Gatsby.

La documentación de Gatsby dirige a los desarrolladores a canales oficiales de la comunidad para distintas necesidades:

• Discord figura como un lugar donde pedir ayuda para desarrolladores a la comunidad.
• GitHub Discussions permite conversar sobre el proyecto y sus funciones.
• La documentación de contribución explica formas de participar en el proyecto.
• El repositorio gatsbyjs/gatsby, que recibe mantenimiento, contiene el código fuente del framework, paquetes, incidencias e historial de contribuciones.

Estos recursos ayudan a los lectores a verificar la documentación, plantear preguntas sobre la implementación e inspeccionar el trabajo público del proyecto. Su existencia no debe convertirse en afirmaciones sin fundamento sobre tiempos de respuesta, longevidad de los paquetes o planes futuros.

Lo que los equipos deben decidir antes de adoptar Gatsby

1. Trazar el mapa del contenido. Identifique cada fuente, las relaciones entre registros, la frecuencia de actualización y qué páginas consumen cada campo. Esto revela si la capa GraphQL normalizada de Gatsby resuelve un problema significativo de coordinación.

2. Asignar un modo de renderizado a páginas representativas. Confirme qué páginas pueden ser estáticas, cuáles podrían diferirse, cuáles requieren getServerData y cuáles son deliberadamente del lado del cliente. Verifique que el destino del despliegue admita la combinación resultante.

3. Auditar el conjunto concreto de dependencias. Compruebe los plugins de origen, plugins de transformación, temas, proyectos iniciales y herramientas de imágenes necesarios frente a la versión de Gatsby del proyecto. Cree prototipos de las integraciones inciertas antes de convertirlas en dependencias arquitectónicas.

4. Probar una carga de trabajo con forma de producción. Gatsby ofrece un framework coherente de React y contenido, pero su idoneidad procede de su adecuación a los datos, las páginas, las integraciones y el modelo de alojamiento del equipo, no de promesas generales sobre velocidad, posiciones en buscadores o escalabilidad sin esfuerzo.