[윈터데브캠프] 팀프로젝트 - API,DB (+요청/응답, 포트)

프로젝트를 경험해보면서 API, DB 등 설계의 중요성을 많이 느꼈다.

프로젝트가 복잡해질수록 소프트웨어도 복잡해지고 이에따라 탄탄한 설계가 가져오는 장점들이 존재함을 몸소 느낄 수 있었다.

1. 우리가 만들고하자는 요구사항(윈터데브캠프의 목표)을 효과적으로 만족시킬 수 있다.
2. 유지보수 측면에서 용이하다.
3. 협업에서 이점을 갖는다.

따라서, API,DB명세를 상세히 하고자 했고, 이에 따라 적용한 방법을 보이고자 한다.

 

내가 생각하는 API 명세를 작성하는 이유는 크게 3가지가 존재한다.

1. 어떤 것을 구현해야하는지 명확히 한다.
2. 협업에 있어 req/res 형태를 공유한다.
3. 정해진 규칙을 따라 API를 명세한다.

이를 만족시키기 위해 기능 명세를 작성하였다. 

기능 명세를 작성한 이유는 시간에 대한 한계가 있기 때문이다.

사용자를 대상으로 하지 않기 때문에 상세 요구사항을 반영할 기능 명세는 필요가 없다. 즉, 꼭 필요한 기능만 구현해도 되는 것이다.

그러나 2달 남짓의 짧은 기간 내에 완성해야하기 때문에 구현하고자 하는 기능들을 정리하고 이를 중요도 순으로 분류하는 절차가 필요했다.

 

또한 기능 명세를 바탕으로 API 명세를 작성하였다.

API 명세를 작성하며 주요하게 고려한 점은 req/res의 통일, 리소스를 찾는 데 효율적인 url 규칙과 HTTP Method이다.

이를 통해 모바일 개발자들로 하여금 효과적인 API 테스트를 가능하게 하고자 하였다.

 

좌 : 기능 명세 / 우 : API 명세

아래 그림은 API 명세 상세 페이지를 클릭했을 때 확인할 수 있는 화면이다. 

서버 배포 현황을 표로 함께 유지한 이유는 포트 관리 및 운영 차원을 고려하기 위함이다.

Gateway 포트가 몇 번인지, 현재 각 서버가 사용중인 포트 번호 범위가 어떻게 되는 지를 통해 백엔드 개발자들의 접근성을 높이고자 하였다.

특히 포트 번호대를 8011~8019와 같이 대역을 부여하여, 해당 대역 내에서 서버를 Scale-Out 하는 것을 고려했다.

서버 배포

 

데이터베이스는 MSA 구조인 만큼 DB를 분리했어야 했다. 그러나 유저 - 인증 각각의 DB를 분리하게 되면 구현하는데 소요 시간이 더 많이 들 것을 우려하여 완벽히 DB를 분리하지 못해 아쉽다.

이 프로젝트의 특징을 반영하기 위해 채팅DB로 NoSQL을 썼다.

추가로 누가 읽었는 지, 어떤 기기로 접속 했는 지, 가장 최근 채팅이 언제인 지 등의 기능을 지원하기 위해 설계하였다.

데이터베이스 구조