Node.js 프로젝트를 시작할 때 따르는 주요 단계

이 기사에서는 Node.js 애플리케이션을 개발할 때 따르는 몇 가지 단계를 강조하고 싶습니다. 이러한 단계는 비즈니스 요구 사항을 충족하고 장기적인 성장을 위해 유연하고 확장 가능한 안정적인 앱을 제공하는 데 도움이 됩니다.

문제를 해결할 수 있는 접근 방식과 기술을 시작하기 전에 어떤 문제를 해결할 것인지 이해해야 합니다. 그렇기 때문에 가장 중요하게 생각해야 할 것은 비즈니스 상황입니다.
생산 후 프로젝트가 어떻게 성장할지, 나중에 비즈니스에 무엇이 필요할지 예측할 수 없습니다. 당신이 할 수 있는 일은 회사에 MVP에 필요한 것이 무엇인지 논의하고 향후 변경 및 마이그레이션에 대비할 수 있도록 확장 가능한 방식으로 프로젝트를 개발하는 것입니다.

MVP에 대한 개념과 목표를 정한 후에는 엔지니어링 수준으로 내려가 애플리케이션의 확장성과 안정성을 보장하는 데 도움이 될 수 있는 접근 방식과 기술을 살펴보겠습니다.

뼈대

모놀리스, 서버리스, 마이크로서비스 등 구현할 아키텍처를 선택하는 것부터 시작하는 것이 좋습니다. 현재로서는 가장 일반적인 아키텍처 접근 방식이 있지만 여기에만 국한되지는 않습니다.
아키텍처를 기반으로 프레임워크를 선택할 수 있습니다. Node.js 생태계에는 많은 프레임워크가 존재하므로 주의하세요.
내 선택은 다음과 같습니다.

• Express.js는 나중에 대체될 소규모 프로젝트나 프로토타입에 적합합니다.

• Nest.js는 여러 아키텍처를 다루고 있는데, 이는 무엇을 사용할지 결정할 때 고려하는 기본 프레임워크입니다. 도메인으로 분할되고 나중에 별도의 마이크로서비스로 변환되는 모놀리스에 적합합니다.

• 마이크로서비스를 고려한다면 분자가 좋을 것 같습니다. 하지만 저는 인프라와 전반적인 개발 프로세스의 복잡성으로 인해 프로젝트가 시작될 때 마이크로서비스를 만드는 것을 별로 좋아하지 않습니다. 모놀리스를 중심으로 마이크로서비스를 구축하거나 모놀리스에서 MS로 마이그레이션하기 위한 탁월한 프레임워크입니다.

• Next.js. 네, 무엇을 사용해야 할지 결정할 때도 고려합니다. 당신이 프로젝트에 참여하는 유일한 엔지니어이거나 모든 엔지니어가 풀스택 개발자라면 완벽합니다. Vercel과 함께라면 많은 혜택을 누리고 빠르게 움직일 수 있습니다. 그러나 나중에는 복잡성으로 인해 백엔드를 별도의 코드베이스로 마이그레이션해야 할 수도 있습니다.

• 서버리스는 환상적이며 아마도 서버리스 아키텍처를 처리하기 위한 유일한 솔루션일 것입니다. 프로토타이핑이나 소규모 API에는 놀라운 기능입니다. 그래도 저는 모노리스나 MS 아키텍처와 함께 추가 서비스로 사용하거나 서버리스가 적합한 좁은 애플리케이션 부분을 처리하는 것을 선호합니다.

타이프스크립트

거의 모든 프로젝트와 아키텍처에 적합합니다. 하지만 여기에서 멈추고 싶지 않습니다. 다양한 기사에서 장점과 단점이 광범위하게 설명되어 있기 때문입니다.

데이터 저장

물론 비즈니스 요구 사항에 따라 SQL 또는 NoSQL 데이터베이스를 선택해야 합니다. 아니면 두 가지 유형의 스토리지가 모두 필요할 수도 있습니다. 저는 제가 작업한 여러 데이터베이스 중에서 자주 선택하고 광범위한 경험을 갖고 있습니다.

• 기본 선택은 PostgreSQL입니다. 최고의 최적화 프로그램 중 하나를 갖춘 완벽한 관계형 스토리지입니다. 대부분의 요구사항을 충족할 수 있습니다.

• 저는 MongoDB, 특히 서버리스 버전을 자주 고려합니다. 관계형 모델의 이점을 활용하는 강력한 데이터베이스이자 대부분의 스토리지가 제공하지 않는 많은 기능을 갖춘 강력한 NoSQL 데이터베이스입니다.

• 관계 이점 없이 강력한 NoSQL 솔루션이 필요하다면 DynamoDB를 고려해 보세요. 나도 자주 사용하지만 주로 프로젝트의 좁은 부분을 처리하는 데 사용됩니다. 이 데이터베이스에는 사용하기 전에 배워야 하는 특별한 디자인이 있으므로 주의하십시오. 많은 테이블을 생성하고 이를 MongoDB 또는 관계형 DB로 사용하려는 사람들처럼 되지 마십시오. 이런 경우 제품이 커지면 큰 문제가 발생하게 됩니다.

또한 제가 자주 사용하는 ElasticSearch, Redis와 같은 비영구적 저장소에 대해서도 언급하고 싶습니다. ElasticSearch는 프로젝트가 시작될 때 좋지 않지만, 나중에 복잡한 색인 및 검색을 처리해야 할 때 고려하여 사용할 수 있습니다. Redis 또는 다른 메모리 데이터베이스는 친숙하고 구현하기 쉽습니다. 프로젝트 초반에도 캐시가 필요한 경우가 자주 있는데, 가지고 있어서 좋네요.

데이터 액세스 계층

여기에서는 제품 측면에 따라 다른 접근 방식을 사용합니다. 나는 ORM으로 시작하여 좁은 부분에서 쿼리 빌더나 원시 SQL로 마이그레이션하는 것을 좋아합니다. NoSQL 데이터베이스의 경우 ODM을 좋아하고 드라이버 사용을 선호한다고는 말할 수 없습니다. 예를 들어 저는 Mongoose를 사용하는 것을 특별히 좋아하지 않으며 대신 Node.js 드라이버를 선택합니다. ODM보다 유연하고 단순하며, 관계형 모델을 사용할 필요가 없다고 생각합니다.

관계형 데이터베이스의 경우 여기서 사용할 수 있는 다양한 라이브러리가 있지만 SQL 데이터베이스를 사용하는 경우 TypeORM을 고려해 볼 수 있습니다.

개발 워크플로

마지막으로 언급하고 싶은 것은 개발 워크플로입니다. 저는 가능한 한 단순하게 유지하고 구현하기 쉬운 도구를 사용하여 워크플로를 자동화하고 필요한 경우 더 유연하고 복잡한 솔루션으로 전환하는 것을 좋아합니다. 고려할 수 있는 도구에 대한 권장 사항은 다음과 같습니다.

• Github 액션. 쉽고 빠르게 구성할 수 있는 뛰어난 CI/CD 도구입니다.

• Dependabot은 패키지를 최신 버전으로 유지하고 취약점을 검색할 수 있는 환상적인 도구입니다.

• 테라폼. 인프라를 관리하는 데 사용합니다. 최소한 몇 사람이 프로젝트에 참여하면 많은 일이 단순화됩니다. 프로젝트가 성장함에 따라 규모가 커지고 더 나은 상태 관리를 위해서는 인프라 관련 코드를 단순하게 유지하기 위해 Terragrunt와 같은 도구가 필요할 것입니다. AWS를 클라우드 공급자로 사용하는 경우 AWS CDK도 사용할 수 있습니다. Typescript를 지원하는 훌륭한 도구이지만 AWS에서만 사용할 수 있으며, 다른 클라우드 인프라의 무언가가 필요한 경우 코드는 Terraform보다 훨씬 더 복잡합니다. 그래서 저는 AWS에서도 Terraform을 선호합니다.

위 내용은 Node.js 프로젝트를 시작할 때 따르는 주요 단계의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!