개발환경 구축
Calit 프로젝트는 백엔드 개발자 없이 프론트엔드 부트캠프에서 만난 3명이서 진행중이여서, 손쉽게 사용가능한 DB 및 API가 필요했다.
따라서 학습 과정중에서 배운 Github과 Firebase를 이용해 개발 환경을 설정하고, 프로젝트의 유저플로우를 기반으로 DB 설계를 진행했다.
Github Action과 Firebase Hosting를 이용해 협업에 필요한 CICD 세팅을, Firebase에서 제공하는 FireStore 덕분에 손쉽게 DB를 구축할 수 있었다.
Firebase를 이용한 개발환경 세팅하기
실시간 업데이트 (FireStore onSnapShot)
Calit 프로젝트에서 가장 중요한 컨셉 중 하나는 협업툴인 만큼 실시간으로 유저간 변경 사항을 공유할 수 있어야 했다.
실시간 통신을 구현하는 방법은 풀링, 웹소켓과 같은 방법 또한 존재하지만 백엔드 개발자가 없는 상황에서 서버를 구현해 통신하는것은 일정에 차질을 야기할 수 있었다.
따라서 우리는 FireStore에서 제공하는 NoSQL Collection의 변경사항을 리슨하는 onSnapShot 메서드를 이용해 진행하기로 결정하였다.
FireStore onSnapShot 공식문서 링크
이 기능을 이용하면 상대적으로 쉽게 실시간 업데이트 기능을 구현할 수 있어 이번 프로젝트에서 주로 사용할 API로 선택하였다.
ERD 설계
Data Modeling을 설계하기 전에, 여러 NoSQL 데이터베이스의 구조를 설명하는 글을 찾아보면서 먼저 RDB처럼 먼저 ERD를 설계한 후 진행하는 방법론을 찾아 우선 ERD 설계를 진행했다.
다행히 이전 항해99 백엔드 부트캠프 수강 중 ERD를 설계해 본 경험이 있어 그리 어렵지 않게 테이블 간 관계를 구성하고 필드를 작성할 수 있었다.
하지만 이 ERD를 RDB가 아닌 NoSQL의 방식에 맞춰 설계하는것은 조금 난이도가 있었다.
루트 구조 컬렉션 VS 하위 컬렉션
FireStore NoSQL 데이터 구조 선택 공식 문서
FireStore의 공식 문서를 통해 NoSQL의 데이터 구조를 선택하는 방법을 확인했을 때 하위 컬렉션, 루트 구조 컬렉션중 선택해야 했다.
하위 컬렉션은 각 문서(documnent) 아래 컬렉션을 생성하는 방법으로 쉽게 컬렉션간 관계를 가지며 하위 컬렉션 간 그룹 쿼리를 실행할 수 있지만, 문서 삭제시 컬렉션이 남는 단점이 있었다. 또한 공식 문서에서 클라이언트에서는 컬렉션 삭제를 권장하지 않고 있었다.
컬렉션 삭제 관련 FireStore 공식문서
루트 구조 컬렉션은 RDB와 유사하게 각 컬렉션이 테이블의 역할을 하고 그 아래 계속해서 row를 쌓아 데이터를 저장하는 방법으로 각 단일 컬렉션에서 강력한 쿼리를 할 수 있지만 계층 구조를 가진 프로젝트에 적합하지 않다.
1차 Data Modeling - 루트 구조 컬렉션
Calit 프로젝트는 백엔드 서버가 없기 때문에 하위 컬렉션 삭제를 진행할 수 없어(공식 문서에서 권장하지 않음.) 이 단점이 없는 루트 구조 컬렉션으로 설계를 1차적으로 진행하였다.
하지만 이 방법으로 진행할 경우 onSnapShot 메서드를 이용해 컬렉션을 리슨하고 있을 경우 불필요한 호출이 너무 많이 진행되어 서버에 무리를 줄 수 있기 때문에 하위 컬렉션 구조로 변경하게 되었다.
2차 Data Modeling - 하위 컬렉션
하위 컬렉션 방법으로 설계를 진행하니 아래와 같이 각 데이터 간 관계를 쉽게 표현할 수 있었고, onSnapShot 메서드를 이용해 리슨해야 할 컬렉션의 크기도 작아지기 때문에 서버에 무리를 최대한 줄일 수 있었다.
(파란색은 Collection, 주황색은 객체배열, 베이지는 하위 Collection)
다만 이 경우 컬렉션을 클라이언트에서 삭제하지 못하는 경우를 대비하여 DB에서 삭제하는 물리적 삭제가 아닌, is_deleted 필드를 문서에 포함하여 논리적 삭제로 진행하기로 하여 해당 문제를 해결할 수 있었다.
정리
이번 프로젝트는 백엔드 개발자 없이 프론트 개발지 3명이서 진행하기 때문에 백엔드 구축에 대해 많은 걱정이 있었다.
하지만 Firebase의 공식 문서를 통해 3명이서 NoSQL 구조에 적합한 데이터 설계 방식등을 점진적으로 학습하면서 최종적으로 유용하게 사용할 수 있는 데이터 모델링을 진행할 수 있었다.
보통 프로젝트를 진행한다면 각자 역할을 분담하여 진행하지만, 동시에 학습을 진행하여 프로젝트에 대한 전체적인 이해를 다같이 공유할 수 있어 정말 유기적인 협업 경험을 할 수 있었다!
다음에는 프로젝트 시작 전 라우터 구조 및 역할분담에 대해 글을 작성하고자 한다!
