TIL.99 Node.js_Project Architecture

이전까지는 Python / Django / MySQL만 다뤄보았다.

이를 이용해 1, 2차 프로젝트를 진행하였다.

 

하지만 한달 인턴 과정에서 Nest.js/TypeORM/MongoDB/Typescript 를 이용해 백엔드 API를 구현해야 했다.

Nest.js 란 

효율적이고 확장 가능한 Node.js 서버 측 애플리케이션 을 구축하기위한 프레임 워크이다

Node.js가 무제노트처럼 새하얀 백지 상태에서 글을 작성하는 것이라고 한다면

Nest.js는 노트에 정해진 규칙과 구조(줄, 표 등의 구조)를 바탕으로 글을 작성해 나가는 것과 같다.

즉 정해진 규칙과 구조가 있으며 이를 따라 개발하기만 하면 안정성, 효율성 두가지를 모두 충족할 수 있다.

(Django와 비슷한 역할이다, 다만 Nest.js에서는 prisma, TypeORM등 내장되어있는 ORM이 없다는것이 차이점이 아닐까 싶다.)

이러한 Nest. js의 기반언어가 Typescript 이다.

이는 추후에 자세히 다뤄보도록 하고 Node 프로젝트의 기본 아키덱쳐를 알아보도록 하자.

 

1. Modularize(모듈화) 란

역할 및 기능에 따라 코드를 분리하는 행위를 말한다.

개발자는 혼자서 개발하는 일이 극히 드물다. 

결국 좋은코드란 협업하기 좋은 코드로도 볼 수 있다.

협업하기 좋은 코드가 필요한 이유를 크게 5가지로 나눠보자

• 확장성(extensibility)

  확장성을 고려하지 않은 코드는 시스템의 규모가 커질수록 문제가 생길 확률이 높다.

• 재사용성(reusability)

  반복되는 로직을 함수로 분리하는 코드상의 재사용성 뿐만 아니라, 우리가 설계한 구조가 재사용 되어야 한다.

• 유지-보수 가능성(maintability)

  여러 로직이 뒤엉켜 있는 코드는 유지 보수가 안된다.

• 가독성(readability) 어려운 로직 일수록 더 가독성이 높아야 한다. 어려운 로직을 쉽고 간단하게 구현하는 것이 좋은 코드다. 프로젝트의 구조 또한 한 눈에 그려져야 한다.

• 테스트 가능성(testability)

  테스트를 하기 쉬운 코드는 모듈화가 잘 되어 있고, 한 가지 역할만 하는 함수 단위의 코드를 의미한다. 프로젝트의 구조도 추상화가 잘 되어있고, 역할이 잘 나뉘어 있는 구조가 테스트하기 쉬운 구조다.

 

혼자서 작성하는 코딩의 경우 이러한 모듈화는 필요가 없을것이다.

하지만 반드시 기억하자. 개발은 혼자서 하는것이 아닌 함께하는 것이며 내 생각과 의도를 코드로 상대방에게 설명 할 수 있어야하며 더 나아가 코드를 보자마자 개발자의 의도를 파악할 수 있는 것이 좋은 코드라고도 할 수 있을것 같다.

개발자에게 있어 모듈화란 선택이 아닌 필수이며, 특히 나같은 백엔드 개발자는 이와 더불어 DB Hit를 항상 고려한 효율적인 로직을 구현해야함을 명심하고 코딩을 해나가야 할 것이다.

 

2. MVC Pattern

인턴과정을 진행하면서 주니어 개발자로서의 필요한 역량을 하나 더 체감하게 되었다.

애초에 처음부터 프로젝트에 투입되어 구조를 설계하고 나아간다면 언어/프레임워크 등에 대한 지식만 있다면 크게 문제가 될 것같지는 않다.

하지만 지금의 나처럼 프로젝트 중간에 투입되어 코드의 구조에 대해 파악할 줄 아는 능력이 필요하다

실제로 이는 굉장히 어려웠다고 생각되는 부분으로 심지어 Python 언어만 알고 있는 나에겐 Typescript로 이루어진 코드를 이해하는 것도 프로젝트의 구조를 파악하는 것도 굉장히 어려웠다.

한 4~5일 정도는 이걸 파악하는데 굉장한 삽집을 하였으며 본격적으로 다음주부터 시작할 수 있을것 같다.

 

만약 지금 작성하고 공부하는 내용을 미리 알았더라면 이것보다는 훨씬 빠른 시간안에 구조를 파악할 수 있지 않았을까? 하는 생각이 든다.

다행히도 코드의 구조를 어떻게 설계하고 관리해야하는지에 대한 질문은 많은 개발자들에 의해 다뤄진 내용이다.

이미 검증되고 좋은 패턴을 이해하고 직접 적용해보는것이 시작이라고 한다!

 

그 중 첫 단추라고 할 것이 바로 MVC Pattern이다.

여기서 MVC란 Model , View, Controller이다.

특히 MVC Pattern은 은 FrontEnd 에서 프로젝트를 관리 할 때에도 사용될 수 있는 레이어링 패턴 입니다. 모든 소프트웨어 로직에 적용가능한 패턴임을 기억하자!

 

출처 : 위코드

Model

서비스에 필요한 모든 데이터는 모델에서 정의된다.

오로지 Model 레이어에 정의된 DB Schema를 통해서만 DB에 접근해 CRUD 로직을 처리 할 수 있다.

Mongo DB 는 비관계형 데이터베이스 이자 Schema less이다.

---

View

SPA(Single Page Application) 과 Mobile App 의 빠른 성장으로 FrontEnd 개발자의 역할이 커짐에 따라서 서비스를 위한 소프트웨어는 FrontEnd 와 BackEnd 로 나뉘게 되었습니다. 본래 MVC는 서버 사이드에서 한번에 다뤄지던 구조 입니다. 예를들어서, Django 의 템플릿 기능이나 Express 에도 ejs 를 사용하면 View 를 구현할 수 있었다.

View 는 쉽게 말해서 클라이언트(유저)와 상호작용이 일어나는 것을 의미 합니다. 화면에 보여주기 위한 역할을 하는 것 입니다. User Interface(유저 인터페이스)가 바로 View 레이어에 있는 코드로 핸들링 됩니다. React, Angular, Vue 같은 라이브러리 또는 프레임워크로 개발하는 앱을 생각하시면 됩니다. 모바일 iOS, 안드로이드 앱도 View 를 담당한다고 할 수 있습니다. (프론트엔드와 백엔드를 모두 포함하는 하나의 서비스 관점에서 보았을 때)

---

Controller

View 레이어에서 유저의 동작이 닿는 곳은 대부분 데이터의 변화가 필요합니다. 예를들어서 내가 담은 장바구니를 보고싶을 때 장바구니 버튼을 클릭하게 되고, 이 때 HTTP 요청이 백엔드 서버로 보내집니다. 이 요청을 받아서 처리하는 곳이 컨트롤러 입니다. View(유저 인터페이스 레이어)와 Model(데이터를 담당하는 레이어)을 잇는 다리 역할을 하는 부분입니다. 유저의 요청을 처리해서 응답하는 부분이라고 할 수 있죠. Controller 는 Model 과 소통하게 됩니다.

---

MVC Pattern 장점

• 염려의 분리 (Seperation of Concerns)

  유저 인터페이스와 관련된 부분은 모두 View 에 의해서 관리되고, 모든 데이터와 관련된 로직은 Model 에 의해서 관리되며 오로지 Controller 에 의해서 Model 에 접근할 수 있게 됩니다. 각각의 레이어가 하는 역할이 명확 합니다.

• 동시적인 개발 (Simultaneous Development) 세개의 레이어로 역할이 나뉘어져 있기 때문에 동시다발적인 개발이 가능합니다. 역할분담에 용이하며 협업이 가능한 프로젝트를 구성할 수 있습니다.

• 수정의 용이함 (Ease of Modification) 다른 레이어에 영향을 주지 않고 문제가 있는 로직을 찾아서 문제를 해결할 수 있습니다.

• 테스트-주도 개발(Test Driven Development) 각각의 레이어, 그리고 그 레이어 속에 속한 각각의 모듈을 테스트 하기 좋습니다.

 

3. Node.js Project Layering

위에서 살펴본 MVC 패턴은 기본 구조로 생각하면 된다.

하지만 오로지 이 두개의 레이어 만을 이용한 로직을 분리하기에는 실제로 한계가 있다.

따라서 아래와 같은 Project Layering과 같은 형태로 레이어링하고 이를 활용하는것이 좋다.

아래의 이미지가 MVC 패턴의 이미지보다 확장된 개념으로 이해하면 되겠다.

출처 : 위코드

 

Route, Controller, Service, Model 각각의 레이어가 하나의 폴더이자 역할을 의미 한다.

상위 개념에서 하위 개념으로 갈수록 데이터를 다루는 로직(DB 접근하는 로직)에 가까워 진다

또한, 각각의 레이어는 오로지! (중요) 오로지! 아래에 있는 레이어에만 의존성을 갖게 된다.

• Route → Controller
• Controller → Service
• Service → Model

이 의존성이 시사하는 바는 굉장히 크고 중요하다.

실제로 이 개념 하나만을 이해하였을때 머릿속에서 전구가 켜졌다. 정말 중요한 개념이며 알고있는것과 모르고 있는것은 정말 큰 차이가 있다고 생가한다.

 

Route는 service 로직이 어떻게 되어있는지 전혀 모르고 관여 조차하지 않는다.

띠라서 Serveice 로직을 변경해도 Route와 Controller 코드를 바꿀 필요가 없다 (import 등 제외)

때때로, 서비스를 구현하다가 RDBMS(관계형 데이터 베이스) → NoSQL(ex. mongoDB) 로 이전하는 경우가 있는데, Route와 Controller 의 로직은 전혀 바뀌지 않은채로 데이터를 다루는 Service 와 Model 의 로직만 변경 해 주면 됩니다.

 

Route → Controller → Service → Model 레이어로 나누었을 때의

위에서 아래로 갈수록 데이터베이스 접근에 근접하게 되며, 핵심 로직을 다룬다고 할 수 있습니다.

출처 : 위코드

---

Project Layering (의존성 순서)

위에서 아래로 갈수록 데이터베이스의 접근에 가까워 집니다. 또한, 위의 레이어는 오직 아래의 레이어에만 의존합니다.

• server.js: Express App 으로 서버를 여는 로직
• app.js: Express App 인스턴스를 만들고, 필요한 미들웨어를 붙이는 로직
• routes: 라우팅(엔드 포인트 나누기) 로직
• controllers: 엔드포인트에 해당하는 함수 로직 - Http 요청에 따른 에러 핸들링, service 로직에서 데이터를 받아와서 응답으로 내보내는 로직
• services: controller 에서 넘겨받은 인자로 다양한 알고리즘(필터, 정렬 등..)을 처리해서 데이터에 접근하는 로직
• prisma (=model): 데이터베이스에 접근하기 위한 모델이 정의되어 있는 폴더

 

아래 모듈은 의존성 없이 다양한 레이어에서 사용될 수 있지만 반복되는 로직이기에 분리해 놓은 폴더 입니다.

• middlewares: 컨트롤러에 닿기 전에 반복되는 로직을 모듈화 해 놓는 폴더 (ex. validateToken - 인증 / 인가)
• utils: 의존성 없이 모든 레이어에서 공통적으로 자주 사용되는 로직을 모듈화 해 놓는 폴더 (ex. errorGenerator)
• .env: 프로젝트 내에서 사용할 환경 변수를 선언해 놓는 곳
• node_modules: 노드 패키지 모듈
• .gitignore: 위의 두 모듈을 깃이 관리하지 않도록 함
• package.json: 노드 모듈을 관리하는 파일

 

출처 : 위코드(춤추는 개발자)

> wecode | 위코드 | 코딩 부트캠프 | 코딩교육

WeCode | 위코드 | 코딩 부트캠프 | 코딩교육