[엘리스 SW 트랙] 1차 프로젝트 : 오피스아워 코멘트 8주차 - 1

 

서버 배포 관련 코멘트

• 만약 백엔드 서버가 프론트 정적 파일 &백엔드 코드를 서빙한다면 어떻게 해야할까요?
  • Express에서 내부적으로 정적 파일을 서빙할 수 있는 함수인 "express.static()" 함수를 사용하면 됩니다.
  • 대신 static() 함수를 사용하려면 route를 지정 해줘야합니다. 페이지 로딩을 위한 route를 지정해줘야 하는거죠

Git 브랜치 전략 관련 코멘트

• 브랜치 전략을 어떻게 나눠가지는게 효율적일까요? 지금 현재 브랜치 상태는 백엔드 / 프론트엔드 브랜치로 나뉘어져 있습니다.
  • 회사의 내부 룰에 따라 다르긴 하지만, 보통 프론트/백엔드 repogitory를 다르게 가져가는 경우가 많습니다. 
  • 같은 레포지토리 안에서 작업을 한다면 프론트엔드 쪽은 Component&기능별로, 백엔드 쪽은 API 기능별로 가져가는 것이 좋습니다.

## 프론트엔드 브랜치 ##
front-dev
  feature
    Login
    Join
    Cart
## 백엔드 브랜치 ##
back-dev
  Feature
     Admin
     Login
     User
     Product

 

백엔드 디렉토리 구조 관련 코멘트

• 디렉터리 구조를 3 Layer(Controller-Service-Data Access)로 진행하려고 합니다. 혹시 다른 좋은 구조가 있을까요?
  • 제일 기본적인 구조로 현재 프로젝트에 적용하기 좋은 구조입니다.
  • 추가로 정보를 더 드리자면 무조건 3 Layer를 가져가지는 않습니다. 회사 내부의 규정에 따라 달라질 수 있는데요. Controller 안에 Service 내용이 담겨있을 수도 있고, API 기능마다 한 소스파일 안에 3 Layer를 가지고 있을 수도 있습니다. 이 부분은 아마 현업에서 다양하게 접하실 수 있을 것 같네요 :)
• 백엔드 디렉터리 3 Layer 참고 링크 
  • https://simsim231.tistory.com/181
  • https://www.softwareontheroad.com/ideal-nodejs-project-structure/

MogoDB & 데이터 스키마 구조 관련 코멘트

• 기존에 RDB(관계형 데이터베이스)에서 작성했던 것처럼 ERD를 작성했습니다. 각 스키마 별로 FK(Foreign Key)를 이렇게 넣어주는게 맞는 걸까요?
  • RDB에서는 그려오신 것처럼 FK를 사용하는게 맞습니다. 다만, 몽고 DB는 Document 형 데이터베이스이기 때문에 몽고 디비에서 FK를 쓴다는건 애매합니다. 몽고DB 구조는 서비스에 따라서 달라질 수 있는 특징을 가지고있습니다.
  • 그렇기 때문에 몽고 디비에서는 FK가 아니라 서브 Document 형식을 넣어놓고 "관계"를 형성해주는 것이 좀 더 좋습니다.
  • 추가로 몽고 DB는 join 연산을 할때 데이터베이스 자체에서 수행해 데이터를 만들어주는 것이 아니라, 날 것 상태의 데잍를 가지고 서버 자원을 써서 join 을 수행합니다. 따라서 RDB 처럼 접근해 정규화 방식으로 데이터 구조를 설계하는 것은 좋은 접근 법이 아니죠.
  • 그렇다면 왜 몽고 DB는 "reference" 라는 걸 통해 데이터들의 관계를 정의할까요? 그건 바로 각 데이터들의 관계를 파악하기 위함입니다. reference가 없다면 각 데이터들의 관계를 파악하기 어렵기 때문이죠. 그래서 몽고DB 같은 경우는 비정규화 데이터 구조 설계를 진행하는 것이 바람직합니다.
• 추후에 필요할 것 같은 데이터들을 "options"라는 테이블에 넣으려고 하는데, 이렇게 넣어도 괜찮을까요?
  • 몽고DB의 장점은 초기 데이터 스키마 구조와, 나중에 필드가 추가된 스키마 구조가 공존할 수 있다는 겁니다. 현재 필요한 데이터들만 정의하시고, 추후에 필요하게 된다면 그때 추가해주시면 됩니다.
• 추후에 필드가 추가가 된다면 데이터 정합성이 깨지지 않을까요?
  • RDB 관점에서는 데이터 정합성이 깨지지만, 몽고 DB는 document 형 DB이기 때문에 문제가 되지 않습니다.
• 부모-자식간의 관계를 설정해 주고 싶은데, 현재는 부모 스키마가 자식 스키마의 정보를 가지고 있는 구조입니다.
  • 데이터 연관관계를 정의할 때, 부모의 데이터가 자식들의 정보를 가지고 있는 것보다 자식들이 부모의 정보를 가지고 있는 것이 좋습니다. 자식의 데이터가 무한정으로 늘어난다면 부모가 가지고 있어야하는 정보가 무한대로 늘어나게 됩니다. 
  • 이럴 경우엔 참조 관계를 역전시켜서 자식 데이터가 부모 데이터를 가지고 있게 하도록 하면 됩니다.

 

 

 

#엘리스트랙 #엘리스트랙후기 #리액트네이티브강좌 #온라인코딩부트캠프 #온라인코딩학원 #프론트엔드학원 #개발자국비지원 #개발자부트캠프 #국비지원부트캠프 #프론트엔드국비지원 #React #Styledcomponent #React Router Dom #Redux #Typescript #Javascript