Monolith에서 Monorepo로: Next.js 마이그레이션 이야기

VS Code의 흰색 커서가 소리 없이 깜박였지만 유형 힌트가 나타나지 않았습니다. 내 동료의 좌절한 한숨이 Slack 통화를 통해 울려 퍼졌습니다. 그의 오래된 컴퓨터는 마침내 TypeScript 제안을 완전히 포기했습니다. Next.js 애플리케이션을 구축한 지 1년이 지나자 우리는 우려했던 벽에 부딪혔습니다. 모놀리식 코드베이스가 너무 커져서 불편함을 느꼈습니다.

모놀리식 시작

처음 이 프로젝트를 시작했을 때는 Next.js가 완벽한 선택인 것 같았습니다. React Router 및 Express를 사용하는 일반 React SPA의 배경 지식과 심지어 초기 PHP 경험을 바탕으로 서버와 클라이언트 코드를 공동 배치한다는 아이디어는 직관적으로 느껴졌습니다. 일반적인 통념에 따라 우리는 기술적인 문제보다는 기능에 따라 코드를 구성했습니다. 인증, 잠재 고객, 계정, 팀 기능 – 각각은 자체 유형, 유틸리티, 상수 및 서버측 코드를 갖춘 자체 모듈에 존재합니다.

초창기에는 "처음에는 아름다웠지"라고 생각했던 기억이 납니다. 계정 모듈 작업은 구성 요소, 후크, tRPC 기능, 심지어 Prisma 파일까지 필요한 모든 것이 단일 폴더 내에 있다는 것을 의미했습니다. 제가 늘 원했던 개발자 경험이었습니다.

균열이 보이기 시작하다

7개월이 지나서 첫 번째 경고 신호가 나타났습니다. TypeScript의 언어 서버가 어려움을 겪기 시작했고 제안이 점점 더 느려지고 빌드 시간이 점점 길어졌습니다. 내 강력한 개발 기계는 여전히 이를 처리할 수 있지만 동료의 오래된 하드웨어는 복잡성에 완전히 굴복했습니다.

우리는 전형적인 엔지니어링 갈림길에 직면했습니다. 문제에 돈을 투자하거나 문제를 제대로 해결하기 위해 엔지니어링 시간을 투자해야 했습니다. 물론, 하드웨어를 업그레이드할 수 있습니다. TypeScript 성능은 생산이 아닌 개발에만 영향을 미칩니다. 하지만 그 솔루션의 어떤 부분은 반창고처럼 느껴졌습니다. 우리는 더 어려운 길을 선택했습니다: Turborepo를 사용하여 모놀리스를 모노레포로 리팩터링하는 것입니다.

마이그레이션 여정

첫 번째 단계는 놀라울 정도로 간단했습니다. 코드를 분할하지 않고 구조를 마이그레이션하는 것이었습니다. 웹 앱이 포함된 앱 폴더를 만들고 ESLint 및 TypeScript 구성을 위한 두 개의 표준 Turborepo 패키지를 추가했습니다. 하지만 실제 테스트는 유형 추론을 유지하면서 핵심 기능을 이동하는 것입니다.

저는 데이터베이스 계층부터 시작하여 모든 Prisma 관련 코드를 자체 패키지로 옮겼습니다. package.json 내보내기를 약간 조정한 후 숨을 참고 기본 앱에서 유형을 확인했습니다. 그들은 완벽하게 일했습니다. 더 좋은 점은 동료가 변경 사항을 적용했을 때 몇 주 만에 처음으로 IntelliSense 제안을 받았다는 것입니다. 우리는 뭔가에 빠져 있었습니다.

다음으로는 논리적으로 보이는 tRPC가 나왔습니다. 이는 서버측 기능의 또 다른 독립된 부분입니다. 그러나 여기서 흥미로운 일이 발생했습니다. "tRPC 이동"으로 시작된 것이 일련의 예상치 못한 종속성으로 이어졌습니다.

• 내가 만든 통합 라이브러리
• MJML과 React 템플릿으로 구축된 메일러 시스템
• Trigger.dev 워크플로가 v2와 v3으로 분할됩니다

배운 교훈

이 마이그레이션을 통해 아키텍처 및 개발 방식에 대한 몇 가지 중요한 교훈을 얻었습니다.

1. 서버-클라이언트 분리 문제: Next.js를 사용하면 서버와 클라이언트 코드를 쉽게 혼합할 수 있지만 이러한 편리함으로 인해 아키텍처가 지저분해질 수 있습니다. 나는 그 의미에 대해 생각하지 않고 경계를 넘어 유형과 상수를 가져오는 나 자신을 발견했습니다.

2. Monorepo로 시작: 오늘 다시 시작한다면 첫날부터 Turborepo로 시작하겠습니다. 종속성과 아키텍처에 대해 건전한 방식으로 생각하게 하면서 복잡성을 최소화합니다.

3. 명시적인 종속성이 더 좋습니다: 모놀리스를 해체하면 종속 관계를 시각화하고 의문을 제기하게 되었습니다. 이러한 연결이 필요합니까? 순환 종속성을 만들었나요? 이러한 제약으로 인해 우리는 더 나은 아키텍처 결정을 내리게 되었습니다.

앞으로 나아갈 길

아직 마이그레이션이 완료되지 않았습니다. 우리의 서버 코드와 공유 유틸리티에는 여전히 적절한 구성이 필요하며, 이제 tRPC와 데이터베이스 계층이 별도로 존재하므로 모듈 구조를 다시 생각하고 있습니다. 하지만 이미 우리의 개발 경험은 극적으로 향상되었습니다.

확장 가능한 Next.js 애플리케이션을 구축하는 사람이라면 모노레포 구조로 시작하는 것을 고려해 보세요. 초기 투자는 최소화되지만 이를 통해 제공되는 아키텍처 가드레일은 매우 중요합니다. 미래의 당신과 팀의 오래된 노트북이 감사할 것입니다.

위 내용은 Monolith에서 Monorepo로: Next.js 마이그레이션 이야기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!