IssueTracker 서버 아키텍쳐

협업을 하던 도중 프로그래밍 실력이 부족하여서 서버 아키텍쳐를 분석해기로 하였다. 팀에 조금이라도 기여하고 싶었고 이번 기회를 통해 실력을 올려야겠다.

서버 폴더 구조

build
 |_ app.js
src
 |_ api
     |_ controllers
     |_ middlewares
     |_ routes
 |_ config
 |_ loaders
     |_ passport
 |_ migrations
 |_ models
 |_ seeders
 |_ services

각 폴더의 역할

• build

  • webpack을 통해 나온 결과물
  • 해당 app.js를 통해 서버를 실행

• src

  • server를 실질적으로 동작시키는 코드를 담고 있는 부분
  • 우리가 실제로 작업하게 되는 공간

• api
  • 우리가 라우터로 처리해야 되는 작업들이 담겨있는 폴더
  • 라우터를 호출하는 부분과 라우터를 통해 사용할 콜백 함수가 담겨있음
• controllers
  • 라우터가 실행되고 나면 실행해야 될 콜백 함수들을 담은 폴더
  • 클라이언트에게 요청을 받으면 다시 클라이언트로 전달할 무언가를 만드는 작업을 하는 곳
• middlewares
  • 라우터에서 클라이언트에서 요청한 작업을 처리하기 전 먼저 처리해야 될 작업들을 미들웨어로 처리
• routes
  • 클라이언트에서 요청하는 라우터를 가지고 있는 폴더
  • 각각의 요청에 맞게 url을 분리한 파일들이 들어감
  • 각각의 라우터는 요청에 해당하는 콜백 함수를 가짐
• config
  • 서버에서 사용할 환경설정을 담아 놓은 폴더
  • db설정, cors설정, 포트 설정등이 들어갈 수 있음
  • 각각의 파일을 살펴보면 현재 개발에서 사용할 환경설정이 존재하고 이 값들은 .env에서 뽑아온 형식으로 구성
• loaders
  • 처음 express 세팅과 db에 대한 세팅, passport 전략이 들어있는 부분
  • 앱을 실행하는 부분에서는 loader의 정보만을 불러서 실행
• migrations
  • 추후에 추가
• models
  • db에서 사용할 테이블을 담아두는 곳
• seeders
  • 추후에 추가

• services
  • api가 처리하는 콜백함수에서 클라이언트에 직접 반환하지는 않지만 서버 내부 로직에서 필요한 작업을 처리
  • api는 서버 내부의 로직까지 처리하면 너무 할 일이 많아져서 controller와 service를 분리함