크왕 앱서비스는 다양한 제출 폼에서 데이터를 수집하고 관리해야 하는 복잡한 작업에 대한 고민을 해결하기 위해 두 가지 데이터 관리 옵션을 고려하였습니다.
- Firebase Firestore (NoSQL) : Firebase는 초기 설정이 간편하고 데이터 모델을 미리 정의하지 않아도 유연하게 변경할 수 있는 장점을 가지고 있습니다. 또한, 예상치 못한 상황에서도 데이터를 쉽게 수정할 수 있어 프로젝트 초기에 적합합니다.
- Supabase (관계형 데이터베이스) : Supabase는 데이터 모델링과 스키마 정의에 시간과 노력이 많이 필요하며, 폼 변경이 어려울 수 있습니다. 그러나 복잡한 데이터 구조에 적합하며 확장성을 고려할 때 선택할 수 있습니다.
우리는 초기 서비스 론칭과 사용자 기반 확장을 고려하여 Firebase를 선택하였습니다. 그러나 부가서비스 데이터 관리에 대한 고민도 필요했습니다. 처음에는 각각의 부가서비스를 별도의 컬렉션으로 관리하려고 했으나 프로젝트의 확장성과 데이터 활용 가능성을 고려하면서 Template 컬렉션을 도입하여 각 부가서비스를 blockKind로 분류하는 새로운 전략을 채택했습니다.
// template 컬렉션 구조
[
문서아이디1(유저가 추가한 폼 메뉴): [
{
blockId: 3,
blockKind: "mailing",
title: "제목",
description: "내용",
createdAt: "오늘날짜",
userId: "~~",
}
],
문서아이디2: [
{
blockId: 2,
blockKind: "bannerimage",
createdAt: "오늘날짜",
images: [imageUrl0, imageUrl1, imageUrl2, imageUrl3],
userId: "~~",
}
],
]
이렇게 Template 컬렉션을 통해 모든 부가서비스를 통합적으로 관리함으로써, 유지보수 작업이 단순화되고 데이터 구조와 스키마 변경이 필요한 경우 Template 컬렉션만 업데이트하면 되므로 복잡한 수정 작업을 피할 수 있고, 모든 데이터를 중앙 집계하고 추출하기 간편해졌습니다.
'React' 카테고리의 다른 글
| 디버깅을 통한 버그 해결 경험 (2) | 2023.09.22 |
|---|---|
| 효율적인 이미지 관리를 위한 코드 리팩토링 (2) | 2023.09.22 |
| Lodash의 Deboucing 활용 - 버튼 중복 클릭 방지 (2) | 2023.09.18 |
| React) 불변성이란? (4) | 2023.06.14 |