분류 Nodejs

다음 Node.js 프로젝트를 위한 완벽한 아키텍처 Flow

컨텐츠 정보

  • 조회 330 (작성일 )

본문

좋은 출발은 반의 싸움이라고 누군가가 나보다 현명하다고 말했다. 새 프로젝트를 시작할 때마다 모든 개발자가 처한 상황을 더 잘 설명 할 수 있는 인용문은 없습니다. 프로젝트 구조를 실용적인 방식으로 배치하는 것은 개발 과정에서 가장 어려운 부분 중 하나이며 실제로는 섬세한 부분입니다.


https://dev.to/bnevilleoneill/the-perfect-architecture-flow-for-your-next-node-js-project-1ail 


여기서 LogRocket에서 작성한 이전 기사를 살펴보면 Node.js 기술에 대한 논의 경로, 사용할 프론트 엔드 프레임 워크 선택 방법에 대한 경로를 정의 할 수 있으며 이제 웹을 구조화하는 방법에 대해 더 깊이 파고들 수 있습니다. 우리가 사용할 기술 스택을 결정한 후 앱.


좋은 아키텍처의 중요성 


프로젝트 아키텍처에서 좋은 출발점이 되는 것은 프로젝트 자체의 수명과 미래의 변화하는 요구에 어떻게 대처할 수 있을 지를 결정하는 데 매우 중요합니다. 나쁘고 지저분한 프로젝트 아키텍처는 종종 다음과 같은 결과를 초래합니다.

  • 읽을 수 없고 지저분한 코드로 인해 개발 프로세스가 길어지고 제품 자체를 테스트하기가 더 어려워 짐
  • 쓸데없는 반복으로 코드를 유지 관리하기가 더 어려워 짐
  • 새로운 기능을 구현하는 데 어려움이 있습니다. 구조가 완전히 엉망이 될 수 있으므로 기존 코드를 엉망으로 만들지 않고 새로운 기능을 추가하면 실제 문제가 될 수 있습니다

이러한 점을 염두에 두고 프로젝트 아키텍처가 매우 중요하다는 데 동의하고 이 아키텍처가 우리에게 어떤 도움이 되는지 결정하는 데 도움이 되는 몇 가지 사항을 선언 할 수도 있습니다.

  • 깨끗하고 읽을 수 있는 코드 달성
  • 애플리케이션 전체에서 재사용 가능한 코드를 달성
  • 반복을 피하도록 도와주십시오
  • 우리의 응용 프로그램에 새로운 기능을 추가 할 때 인생을 더 쉽게

Flow 설정 


이제 우리는 일반적으로 응용 프로그램 구조 흐름이라고 하는 것을 논의 할 수 있습니다. 응용 프로그램 구조 흐름은 응용 프로그램을 개발하는 동안 채택 할 규칙과 일반적인 관행입니다. 수년 간의 기술 작업 경험과 올바르게 작동하는 것과 그렇지 않은 것을 이해 한 결과입니다.

이 기사의 목적은 Node.js 애플리케이션을 개발할 때 완벽한 흐름 구조를 설정하기 위한 빠른 참조 안내서를 작성하는 것입니다. 규칙을 정의 해 보겠습니다.


규칙 #1 : 파일을 폴더로 올바르게 구성 


모든 것이 우리의 응용 프로그램에 있어야 하며 폴더는 공통 요소를 그룹화 하기에 완벽한 장소입니다. 특히, 우리는 매우 중요한 분리를 정의하여 규칙 #2를 얻습니다.


규칙 #2 : 비즈니스 로직과 API 경로를 명확하게 분리 


Express.js와 같은 프레임 워크는 놀랍습니다. 요청,보기 및 경로 관리를 위한 놀라운 기능을 제공합니다. 이러한 지원으로 비즈니스 로직을 API 경로에 넣는 것이 유혹적일 수 있습니다. 그러나 이것은 빠르게 그것들을 거대하고 모 놀리 식 블록으로 만들어서 다루기 어렵고 읽기 어려우며 분해되기 쉬운 것으로 드러날 것입니다.


또한 개발 시간이 길어지고 애플리케이션의 테스트 가능성이 어떻게 저하 될지 잊지 마십시오. 이 시점에서“ 이 문제를 어떻게 해결합니까? 비즈니스 로직을 명확하고 지능적으로 어디에 배치 할 수 있습니까?”정답은 규칙 #3에 나와 있습니다.


규칙 #3 : 서비스 계층 사용 


이곳은 모든 비즈니스 로직이 살아야 하는 곳입니다. 기본적으로 앱의 핵심 로직을 구현할 메소드가 있는 클래스 모음입니다. 이 계층에서 무시해야 할 유일한 부분은 데이터베이스에 액세스하는 부분입니다. 데이터 액세스 계층에서 관리해야 합니다.

이 세 가지 초기 규칙을 정의 했으므로 결과를 다음과 같이 그래픽으로 나타낼 수 있습니다.


Separating Business Logic From API Routes 


그리고 우리를 규칙 #1로 다시 보내는 후속 폴더 구조는 다음이 될 수 있습니다.


Our Node Application's Folder Structure 


이 마지막 이미지를 보면 구조에 대해 생각할 때 두 가지 다른 규칙을 설정할 수도 있습니다.


규칙 #4 : 구성 파일에 구성 폴더 사용 


Config Folder And Configuration Files 


규칙 #5 : 긴 npm 스크립트를 위한 스크립트 폴더가 있어야 합니다. 


Scripts Folder 


규칙 #6 : 의존성 주입 사용 


Node.js는 말 그대로 우리의 삶을 편하게 해주는 놀라운 기능과 도구로 가득합니다. 그러나 우리가 알고 있듯이 테스트 가능성과 코드 관리 효율성으로 인해 발생할 수 있는 문제로 인해 종속성 작업은 대부분 번거로울 수 있습니다.


이를 위한 솔루션이 있으며 이를 의존성 주입이라고 합니다.


의존성 주입은 하나 이상의 의존성 (또는 서비스)이 의존성 개체에 주입되거나 참조에 의해 전달되는 소프트웨어 디자인 패턴입니다. 


이것을 Node 어플리케이션 내에서 사용함으로써,

  • 더 쉬운 단위 테스트 프로세스를 사용하여 하드 코딩 대신 사용하려는 모듈에 직접 종속성을 전달하십시오.
  • 쓸모없는 모듈 결합을 피하여 유지 보수가 훨씬 쉬워집니다.
  • 더 빠른 git flow를 제공하십시오. 인터페이스를 정의한 후에는 인터페이스가 그대로 유지되므로 병합 충돌을 피할 수 있습니다.

Node Without Dependency Injection 


코드에 대한 접근 방식으로는 단순하지만 여전히 유연하지 않습니다. 예제 데이터베이스를 사용하도록 이 테스트를 변경하려면 어떻게 됩니까? 이 새로운 요구에 맞게 코드를 수정해야 합니다. 대신 데이터베이스를 직접 종속성으로 전달하지 않습니까?


Passing Database As A Dependency 


규칙 #7 : 단위 테스트 사용 


벨트 아래에 의존성 주입이 있음을 알았으므로 프로젝트에 대한 단위 테스트를 구현할 수도 있습니다. 테스트는 애플리케이션 개발에서 매우 중요한 단계입니다. 버그가 있는 코드로 인해 개발 프로세스가 느려지고 다른 문제가 발생할 수 있기 때문에 최종 결과 뿐만 아니라 프로젝트의 전체 흐름이 프로젝트에 달려 있습니다.

애플리케이션을 테스트하는 일반적인 방법은 단위로 테스트하는 것입니다. 목표는 코드 섹션을 분리하고 정확성을 확인하는 것입니다. 절차 적 프로그래밍과 관련하여 단위는 개별 기능 또는 절차 일 수 있습니다. 이 프로세스는 일반적으로 코드를 작성하는 개발자가 수행합니다.


이 방법의 장점은 다음과 같습니다.


향상된 코드 품질 


단위 테스트는 코드의 품질을 향상 시켜 코드가 다른 개발 단계로 진행되기 전에 놓친 문제를 식별하는 데 도움이 됩니다. 가장자리를 드러내고 전반적인 코드를 더 잘 작성합니다.


버그는 이전에 발견되었습니다 


여기서 문제는 매우 초기 단계에서 발견됩니다. 테스트는 코드를 작성한 개발자가 수행하므로 버그가 더 일찍 발견되므로 시간이 많이 걸리는 디버깅 프로세스를 피할 수 있습니다.


비용 절감 


응용 프로그램의 결함이 적다는 것은 디버깅에 소요되는 시간이 적고 디버깅에 소요되는 시간이 적다는 것은 프로젝트에 소요되는 비용이 적다는 것을 의미합니다. 이 소중한 장치를 이제 제품의 새로운 기능을 개발하기 위해 할당 할 수 있으므로 여기에 시간이 특히 중요한 요소입니다.


규칙 #8 : 써드 파티 서비스 호출에 다른 계층 사용 


종종 응용 프로그램에서 타사 데이터를 호출하여 특정 데이터를 검색하거나 일부 작업을 수행하려고 할 수 있습니다. 그럼에도 불구하고 이 호출을 다른 특정 계층으로 분리하지 않으면 관리하기에 너무 큰 제어 할 수 없는 코드 조각이 발생할 수 있습니다.


이 문제를 해결하는 일반적인 방법은 pub / sub 패턴을 사용하는 것입니다. 이 메커니즘은 게시자라는 메시지를 보내는 엔터티와 구독자라는 메시지를 받는 엔터티가 있는 메시징 패턴입니다.


게시자는 메시지를 특정 수신자에게 직접 보내도록 프로그래밍 하지 않습니다. 대신, 어떤 구독자가 어떤 메시지를 처리하는지 알지 못한 채 게시 된 메시지를 특정 클래스로 분류합니다.


비슷한 방식으로 구독자는 하나 이상의 클래스를 처리하는 데 관심을 표명하고 관심 있는 메시지 만 수신합니다. 모든 게시자가 어디에 있는지 알지 못합니다.

발행-구독 모델을 사용하면 이벤트 중심 아키텍처 및 비동기 병렬 처리가 가능하지만 성능, 안정성 및 확장 성이 향상됩니다.


규칙 #9 : 린터 사용 


이 간단한 도구를 사용하면 더 빠르고 전반적으로 더 나은 개발 프로세스를 수행 할 수 있으므로 전체 응용 프로그램 코드를 균일하게 유지하면서 작은 오류를 주시할 수 있습니다.


Example Of Using A Linter 


규칙 #10 : 스타일 가이드 사용 


코드를 일관된 방식으로 올바르게 형식화 하는 방법에 대해 여전히 생각하십니까? Google 또는 Airbnb가 제공 한 놀라운 스타일 가이드 중 하나를 채택 해 보시겠습니까? 코드를 읽는 것이 훨씬 쉬워 질 것입니다.이 중괄호를 올바르게 배치하는 방법을 이해하려고 해도 좌절하지 않을 것입니다.


Google's JavaScript Style Guide 


규칙 #11 : 항상 코드 주석 


무엇을 하고 있는지, 무엇보다 왜 이해하기 어려운 어려운 코드를 작성 하는가? 그것을 언급하는 것을 잊지 마십시오. 이것은 동료 개발자와 미래의 자아에게 매우 유용 할 것입니다. 모두가 처음 6 개월 후에 정확히 왜 당신이 무언가를 했는지 궁금해 할 것입니다.


규칙 #12 : 파일 크기를 주시하십시오 


너무 긴 파일은 관리 및 유지 관리가 매우 어렵습니다. 항상 파일 길이를 주시하고 너무 길어지면 폴더에 묶여있는 모듈로 묶은 파일을 서로 관련된 파일로 분할하십시오.


규칙 #13 : 항상 gzip 압축 사용 


서버는 gzip 압축을 사용하여 파일을 웹 브라우저로 보내기 전에 파일 크기를 줄일 수 있습니다. 지연 시간과 지연이 줄어 듭니다.


Gzip Compression With Express 


규칙 #14 : 약속 사용 


콜백을 사용하는 것이 JavaScript에서 비동기 코드를 처리 할 수 있는 가장 간단한 메커니즘입니다. 그러나 원시 콜백은 종종 동기 코드를 사용할 때 우리에게 익숙한 응용 프로그램 제어 흐름, 오류 처리 및 의미를 희생 시킵니다. 이를 위한 솔루션은 Node.js에서 약속을 사용하는 것입니다.


약속은 더 나은 오류 처리 플랫폼과 함께 기능적 프로그래밍 의미론을 제공하면서 코드를 더 쉽게 읽고 테스트 할 수 있게 하여 단점보다 더 많은 장점을 가져옵니다.


Basic Example Of A Promise 


규칙 #15 : 약속의 오류 처리 지원 사용 


앱에서 예기치 않은 오류 또는 동작이 발생하지 않는 상황에서 자신을 찾는 것은 전혀 유쾌하지 않습니다. 코드를 작성할 때 오류를 피할 수 없습니다. 그것은 단순히 인간의 일부입니다.


그것들을 다루는 것은 우리의 책임이며, 우리는 항상 응용 프로그램에서 약속을 사용해야 할 뿐만 아니라 catch 키워드가 제공하는 오류 처리 지원을 사용해야 합니다.


Error Handling With Promises 


결론 


Node.js 응용 프로그램을 만드는 것이 어려울 수 있습니다.이 규칙 세트를 사용하면 사용할 아키텍처 유형과 해당 아키텍처를 지원하는 사례를 설정할 때 올바른 방향으로 전환하는 데 도움이 되었기를 바랍니다.