Gatsby를 Astro로 마이그레이션 | Social Animal

개발자들이 Gatsby에서 Astro로 이동하는 이유

Gatsby는 좋은 성과를 거뒀습니다. React 기반 정적 사이트 생성기 카테고리를 개척했고 수천 명의 개발자들을 JAMstack으로 소개했습니다. 하지만 그것은 정체되었습니다. Netlify는 2023년 초 Gatsby를 인수했고, 개발이 느려지고 있으며, 플러그인 생태계가 악화되고 있으며, 대규모 콘텐츠 사이트의 빌드 시간은 여전히 고통스럽게 느립니다.

Astro는 정확히 Gatsby가 만든 문제를 해결하도록 구축되었습니다. 기본적으로 JavaScript 없음, GraphQL 복잡성을 대체하는 콘텐츠 컬렉션, Gatsby를 부끄럽게 만드는 빌드 시간. Gatsby 콘텐츠 사이트를 유지 관리하고 있다면, Astro로의 마이그레이션은 단순한 업그레이드가 아닙니다. 이미 늦은 것입니다.

마이그레이션을 촉진하는 Gatsby 통증 포인트

단순 데이터에 대한 GraphQL 복잡성

Gatsby의 GraphQL 데이터 레이어는 출시되었을 때 혁신적이었습니다. 또한 대부분의 콘텐츠 사이트에 엄청난 과도함이었습니다. 블로그 게시물을 나열하고 싶으신가요? GraphQL 쿼리를 작성합니다. 마크다운 파일에서 frontmatter를 가져오고 싶으신가요? GraphQL 쿼리. 이미지를 표시하고 싶으신가요? 특수 컴포넌트로 래핑된 GraphQL 쿼리입니다.

50페이지의 마케팅 사이트의 경우, 파일 시스템에 존재하는 콘텐츠를 렌더링하기 위해 수십 개의 GraphQL 쿼리를 유지 관리하고 있습니다. 추상화는 비례적 이점 없이 인지적 오버헤드를 추가합니다.

규모가 좋지 않은 빌드 시간

Gatsby의 빌드 파이프라인은 모든 페이지를 GraphQL 레이어를 통해 처리하고, 이미지 변환을 실행하며, 각 경로에 대한 전체 React 번들을 생성합니다. 500페이지 콘텐츠 사이트는 10-15분이 걸릴 수 있습니다. 2,000페이지 사이트? 증분 빌드를 활성화한 경우에도 30분 이상 보고 있습니다.

모든 콘텐츠 업데이트는 대기를 의미합니다. 모든 오타 수정은 대기를 의미합니다. 콘텐츠 팀은 도구를 증오하기 시작합니다.

플러그인 생태계가 부패하고 있습니다

Gatsby의 강점은 플러그인 생태계였습니다. gatsby-plugin-image, gatsby-plugin-sharp, gatsby-source-filesystem, gatsby-transformer-remark. 이러한 플러그인 중 많은 것이 1년 이상 의미 있게 업데이트되지 않았습니다. 의존성 충돌이 증가합니다. 보안 권고가 쌓입니다. npm audit을 실행하면 47개의 취약점이 표시되고, 대부분은 Gatsby 의존성 트리 깊숙이 묻혀 있습니다.

무거운 JavaScript 번들

Gatsby는 상호 작용이 전혀 필요하지 않은 페이지를 포함하여 모든 방문자에게 전체 React 런타임을 제공합니다. 정적 "About Us" 페이지도 React, ReactDOM 및 Gatsby의 런타임을 다운로드합니다. Lighthouse 점수가 저하되고, Core Web Vitals이 하락하며, 느린 연결의 사용자가 대가를 치릅니다.

Astro가 제공하는 것

콘텐츠 컬렉션이 GraphQL을 대체합니다

Astro의 콘텐츠 컬렉션은 콘텐츠 사이트를 위해 목적-구축되었습니다. TypeScript에서 스키마를 정의하고, 마크다운 파일을 폴더에 드롭한 후, getCollection('blog')로 쿼리합니다. GraphQL이 없습니다. 특수 플러그인이 없습니다. 기본적으로 유형 안전 frontmatter 검증이 제공됩니다.

// src/content/config.ts
import { defineCollection, z } from 'astro:content';

const blog = defineCollection({
  schema: z.object({
    title: z.string(),
    date: z.date(),
    tags: z.array(z.string()),
    image: z.string().optional(),
  }),
});

그것이 전부입니다. gatsby-node.js가 없고, createPages API가 없고, GraphQL 조각이 없습니다. 데이터 가져오기는 필요한 컴포넌트의 단일 함수 호출입니다.

기본적으로 JavaScript 없음

Astro는 명시적으로 옵트인하지 않는 한 클라이언트 측 JavaScript를 제공하지 않습니다. 50페이지 마케팅 사이트는 순수 HTML과 CSS를 브라우저로 보냅니다. 상호 작용이 필요할 때(연락 양식, 이미지 캐러셀, 검색 위젯), Astro의 Islands 아키텍처를 사용하여 해당 컴포넌트만 수화합니다.

결과: 모바일에서 최적화 트릭 없이 95-100의 Lighthouse 점수입니다.

1초 미만의 빌드

Astro는 Vite에서 실행됩니다. 500페이지 콘텐츠 사이트는 30초 미만에 빌드됩니다. 2,000페이지 사이트는 2분 미만에 빌드됩니다. 개발 중 Hot module replacement는 즉시입니다. 콘텐츠 팀은 Gatsby의 개발 서버가 GraphQL 스키마를 재컴파일하기를 기다리는 대신 밀리초 단위로 변경 사항을 미리 볼 수 있습니다.

프레임워크 불가지론 컴포넌트

Gatsby 사이트에서 이미 React 컴포넌트가 있습니까? Astro는 빌드 시간에 또는 클라이언트 측에서 렌더링합니다. Astro 컴포넌트로 점진적으로 마이그레이션하려고 하거나, 특정 기능을 위해 Vue 또는 Svelte를 시도하고 싶으신가요? Astro는 같은 프로젝트에서 모두 지원합니다.

당사의 Gatsby to Astro 마이그레이션 프로세스

1단계: 감사 및 아키텍처(1주차)

우리는 기존 Gatsby 사이트를 매핑하는 것으로 시작합니다. 모든 페이지 템플릿, 모든 GraphQL 쿼리, 모든 플러그인 의존성, 모든 동적 경로. 우리는 gatsby-node.js 구성을 문서화하고, 사용자 정의 소스 플러그인을 식별하며, 모든 타사 통합을 카탈로그화합니다.

거기서 우리는 Astro 아키텍처를 설계합니다: 콘텐츠 컬렉션 스키마, 레이아웃 계층 구조, 통합 선택 및 배포 대상입니다.

2단계: 콘텐츠 마이그레이션(2주차)

우리는 Gatsby의 구조에서 Astro 콘텐츠 컬렉션으로 콘텐츠를 변환하는 자동화된 마이그레이션 스크립트를 구축합니다. Frontmatter 스키마는 검증되고 정규화됩니다. MDX 컴포넌트는 Astro 등가물에 매핑되거나 프레임워크 아일랜드로 래핑됩니다.

Gatsby의 gatsby-image 사용은 Astro의 내장 <Image /> 컴포넌트로 변환됩니다. 플러그인 체인이 필요하지 않은 반응형 이미지, 형식 변환 및 게으른 로딩을 기본적으로 처리합니다.

3단계: 템플릿 및 컴포넌트 변환(2-3주차)

Gatsby 페이지 템플릿은 Astro 레이아웃 및 페이지가 됩니다. 클라이언트 측 상호 작용이 필요하지 않은 React 컴포넌트는 Astro 컴포넌트가 됩니다. 더 간단하고, 더 빠르며, JavaScript 없습니다. 대화형 컴포넌트는 React로 유지되고(또는 다시 작성되며) 부분 수화를 위해 client: 지시문을 사용합니다.

우리는 Gatsby 플러그인을 Astro 통합으로 대체합니다:

• gatsby-plugin-sitemap → @astrojs/sitemap
• gatsby-plugin-feed → @astrojs/rss가 있는 사용자 정의 RSS
• gatsby-plugin-mdx → @astrojs/mdx를 통한 내장 MDX 지원
• gatsby-plugin-sharp → 내장 astro:assets 이미지 최적화

4단계: SEO 보존(3주차)

이것이 마이그레이션이 살거나 죽는 곳입니다. 우리는 철저한 URL 보존 전략을 구현합니다:

• 301 리다이렉트: URL 구조 변경의 경우, 0-레이턴시 리다이렉트를 위해 호스팅 레벨에서 구성됨
• 정규 태그: 기존 URL 구조와 일치하는 모든 페이지
• 구조화된 데이터: 마이그레이션 및 Google의 Rich Results 테스트에 대해 검증된 JSON-LD
• 메타 태그: 정확하게 보존됨. 제목 태그, 설명, Open Graph, Twitter Cards
• XML 사이트맵: 재생성되고 Google Search Console에 제출됨
• 내부 링크 감사: 마이그레이션 후 끊긴 참조를 잡음

우리는 30일 동안 Google Search Console을 모니터링하여 인덱싱 문제를 즉시 포착합니다.

5단계: 테스트 및 출시(4주차)

기존 Gatsby 사이트에 대한 전체 시각적 회귀 테스트. 성능 벤치마크는 나란히 비교됩니다. 접근성 감사. 크로스 브라우저 테스트. 우리는 스테이징 URL에 배포하여 팀이 검토한 다음 다운타임 없이 컷오버합니다.

Gatsby 사이트에서 서비스 워커를 사용하고 있었다면(gatsby-plugin-offline에서 일반적임), 우리는 기존 방문자의 브라우저에서 캐시 무효화를 강제하는 대체 서비스 워커를 배포합니다. 대부분의 마이그레이션 가이드가 완전히 건너뜁니다.

타임라인 및 가격

50-200페이지의 콘텐츠 사이트에 대한 일반적인 Gatsby to Astro 마이그레이션은 3-4주에 실행되며 $8,000부터 시작합니다. 사용자 정의 소스 플러그인, 복잡한 동적 라우팅 또는 무거운 CMS 통합이 있는 더 큰 사이트에는 5-6주가 필요할 수 있습니다.

범위 요인에는 다음이 포함됩니다: 고유 페이지 템플릿의 수, 사용자 정의 Gatsby 플러그인, 타사 API 통합 및 React 컴포넌트를 유지할지 아니면 모든 것을 네이티브 Astro로 변환할지 여부.

최종 결론

Gatsby는 죽지 않았지만 더 좋아지고 있지 않습니다. Astro는 적극적으로 개발되고 있으며, 번성하는 커뮤니티가 있으며, 콘텐츠가 많은 웹사이트를 위해 처음부터 설계되었습니다. 마이그레이션 경로는 잘 문서화되어 있으며, 성능 이득은 즉각적이며, 개발 팀은 GraphQL 보일러플레이트를 제거해서 감사할 것입니다.

정체되어 있는 프레임워크 유지 관리를 중지합니다. 빠르게 움직이고 있는 것으로 이동하십시오.