Talently
Talently
Gatsby

Gatsby

The React framework for high-performance static websites

Gatsby is a React framework focused on static site generation and high-performance web applications. Based on GraphQL for the data layer and with a robust plugin ecosystem, it allows building ultra-fast sites consuming data from multiple sources like CMS, APIs, and local files, automatically optimizing images, scripts, and assets.

ReactGraphQLSSGPerformance

Market demand

Gatsby has stable demand in digital marketing projects, corporate blogs, and content sites where performance and SEO are critical. It has lost some traction against Next.js for dynamic applications, but remains a solid option for static sites with multiple data sources.

Strong in marketing and contentStable demand in digital agenciesReference in JAMstack

Technical requirements

Intermediate

Requires mastery of React, GraphQL concepts for querying the data layer, and familiarity with the static site build cycle. Knowledge of web performance and Core Web Vitals is valuable for leveraging Gatsby's automatic optimizations.

Use cases

Real Projects

Gatsby is used to develop:

  • High-performance marketing sites and landing pages
  • Corporate blogs and editorial content sites
  • Product technical documentation
  • Portfolios and presentation sites with multiple data sources

Types of Company

Gatsby is adopted by:

  • Digital agencies with marketing clients
  • Companies with high-traffic content sites
  • Startups with conversion-oriented landing pages
  • Organizations with public technical documentation

Production Scenarios

Gatsby is widely used in production environments such as:

  • Sites with content from headless CMS like Contentful or Sanity
  • Blogs with high volume of statically generated articles
  • Landing pages with multiple data source integration
  • Documentation sites with integrated search

Scalability

Gatsby offers multiple mechanisms to scale applications:

  • Gatsby Cloud with incremental builds for large sites
  • CDN integration for global distribution of static content
  • Deferred Static Generation for low-priority pages
  • Slice API for shared components that don't require full rebuild

Advantages and Disadvantages

Advantages

Automatic performance optimizations for images, scripts, and fonts.

Plugin ecosystem to integrate any data source without configuration.

Excellent Core Web Vitals scores by default on well-built sites.

Disadvantages

Long build times on sites with thousands of pages without incremental builds.

GraphQL as a data layer can be excessive for simple projects.

Has lost traction against Next.js which covers similar use cases with more flexibility.

Comparison

Advantages of Next.js

  • Greater flexibility combining SSR, SSG, and ISR
  • Greater adoption and more active ecosystem
  • Better for applications with dynamic content

Considerations

Next.js has surpassed Gatsby in adoption by covering both static sites and dynamic applications. Gatsby remains competitive for pure content sites with multiple data sources where its plugin ecosystem adds real value.

Basic questions

Gatsby is preferable when the project consumes data from multiple sources like CMS, APIs, and local files thanks to its plugin ecosystem and unified GraphQL. Also when the team already has Gatsby experience or the project is purely static without the need for dynamic SSR.
It allows integrating data sources like Contentful, WordPress, Shopify, or Markdown with minimal configuration. Transformation, image optimization, and performance plugins automate tasks that in other frameworks require manual configuration, significantly accelerating development.
GraphQL acts as a unified data layer that normalizes data from multiple sources into a single queryable graph. It allows components to request exactly the data they need regardless of its origin, whether a CMS, a REST API, or local files.
When maximum performance with a static site is needed, flexibility to use React in components, integration with multiple data sources, or a modern development process with version control for both code and content.
Image optimization and conversion to modern formats with gatsby-plugin-image, automatic code splitting by route, prefetching of linked pages, critical CSS inlining, and deferring non-critical scripts, generating high Lighthouse scores by default.
Through file system-based routing where files in the pages folder automatically generate routes. Dynamic pages are created programmatically in gatsby-node.js using createPage with data obtained from the GraphQL layer during the build.
It is the centralized GraphQL layer that aggregates data from all sources configured through source plugins. It allows querying data from any origin with the same GraphQL syntax from any component, regardless of where the data originally comes from.
In content sites with multiple external data sources where the plugin ecosystem adds real value, in projects where automatic performance optimizations are a priority, or in React teams building marketing sites with strict Core Web Vitals requirements.

Technical questions

Gatsby first executes gatsby-node.js to create data nodes and programmatic pages, then generates the GraphQL graph aggregating data from all source plugins, then renders each page as static HTML with React, and finally optimizes assets like images and scripts for the final bundle.
gatsby-config.js configures plugins and site metadata. gatsby-node.js runs code on the server during the build to create pages and modify the data graph. gatsby-browser.js runs code in the browser to manage the client lifecycle like wrapping the application or actions on route changes.
By querying data in gatsby-node.js with GraphQL during the build, iterating over the results, and calling createPage with the corresponding React template and node data as context. The template receives the data through a page query with the context variable.
It is the official image optimization plugin that automatically generates multiple sizes, converts to modern formats like WebP and AVIF, implements lazy loading with placeholder, reserves space to prevent layout shift, and serves the appropriate size based on the user's device.
Using Deferred Static Generation for low-priority pages that are generated on the first request, CMS webhooks that trigger automatic rebuilds on Gatsby Cloud or CI/CD platforms, or supplementing with client-side API calls for very dynamic data that cannot wait for a rebuild.
Using StaticQuery or the useStaticQuery hook for data in non-page components, page queries in page templates for data specific to each route, and GraphQL fragments to reuse common query parts across multiple components.
Using client-only routes for pages that require authentication or user data, client-side API calls with useEffect or React Query for real-time data, and external services like Netlify Functions or AWS Lambda for backend logic without a dedicated server.
By enabling Deferred Static Generation for low-priority pages that can be generated on demand, using incremental builds on Gatsby Cloud that only regenerate pages whose data changed, and optimizing GraphQL queries to minimize processing during the build.

Advanced questions

By organizing page templates by content type, using GraphQL fragments to share common fields between queries, separating page creation logic in gatsby-node.js by content type, and configuring source plugins with specific options for each source in gatsby-config.js.
Using client-only routes for preview routes that are not statically generated, consuming the CMS preview API from the client with preview credentials, and displaying unpublished content. A preview URL is configured in the CMS pointing to this special application route.
When the site needs SSR for personalized content, when build times become unmanageable without Gatsby Cloud, or when Next.js better covers the project's use cases. The migration involves replacing the GraphQL layer with Next.js's fetching system and adapting the file-based routing.
By auditing with Lighthouse and Web Vitals regularly, always using gatsby-plugin-image for all images, loading fonts with gatsby-plugin-google-gtag or optimizing self-hosted fonts, minimizing third-party JavaScript with deferred loading, and monitoring real metrics with tools like Speedcurve.
By implementing a source plugin with the sourceNodes function that fetches data from the internal source and converts it into graph nodes with createNode. Node types are defined with createTypes in gatsby-node.js and available GraphQL queries are documented so components can consume them.
By creating pages per language in gatsby-node.js with localized route prefixes, using gatsby-plugin-react-i18next for translation management with lazy loading, configuring hreflang in the head of each page for SEO, and generating localized sitemaps with gatsby-plugin-sitemap.

Common interview mistakes

Proposing Gatsby without evaluating Next.js for cases where both are viable reflects a lack of judgment about the current ecosystem. Being able to articulate when Gatsby still adds value over Next.js and acknowledging that Next.js has gained ground in many use cases is expected.
Proposing Gatsby for projects with highly dynamic or personalized content without evaluating the implications of rebuild times reflects not understanding the static model. Knowing when Next.js's ISR or SSR is more suitable is expected.
Not knowing Deferred Static Generation or incremental builds when working with high-volume sites reflects little experience with Gatsby in real production.
Using standard img tags instead of GatsbyImage or StaticImage components removes the automatic optimizations that are one of Gatsby's main values. It is a frequent mistake among developers coming from React without specific Gatsby experience.
Putting all page creation logic in a single gatsby-node.js file without separation by content type generates hard-to-maintain code in large projects. Not knowing how to organize this file reflects little experience in medium or large-scale Gatsby projects.
Using useStaticQuery in page templates or page queries in non-page components reflects not understanding the restrictions of Gatsby's query system. It is a frequent confusion among developers new to the framework.