데브폴리오 strapi 사용기 (1) - firestore vs Headless CMS 선택하기

데브폴리오를 개발하기 시작했을 때는 앞으로 서비스 규모가 어떤 방향으로 얼마나 확장될지 불투명했다. 토이프로젝트 큐레이팅 해주는 서비스에 대한 반응이 어떨지 테스트하는 것이 주목적이었다.

초기 버전에서 제공하고자 하는 핵심 기능은 심플했다 - 방문자에게 괜찮은 토이프로젝트 정보를 보여주는 것. 여기서 기능을 추가하더라도 로그인, 좋아요, 댓글 정도가 되지 않을까. 그래서 서버 구축 및 관리 리소스를 줄이고 싶었다.

결국 strapi 라는 Headless CMS를 사용해보기로 했고, 현재 4개월째 잘 사용하고 있다. 비슷하게 백엔드 없이 프로젝트를 개발할 프론트 개발자들에게 참고가 되길 바라며 내 경험을 적어본다.

firestore vs Prismic (Headless CMS)

그동안 백엔드 없이 프론트만 개발한 프로젝트 경험이 2번 있었다. 하나는 firebase의 firestore를 DB로 사용해서 데이터를 관리했고 또 하나는 Prismic이라는 Headless CMS 서비스를 이용해서 정적인 사이트의 컨텐츠를 관리했다. 하나라도 만족스러운 경험이 있었다면 큰 고민 없이 다시 사용했겠지만 둘 다 아쉬운 점이 조금씩 있었다.

firestore의 장단점

• firestore의 장점은 프론트 개발자가 하나의 코드베이스 안에서 javascript로 백엔드 서비스에 준하는 기능을 직접 짤 수 있는 점이라고 생각한다.
• 그러나 firestore 의 독자적인 쿼리 방식을 새로 배우는 것이 나에겐 큰 난관이었다. 물론 새로운 기술을 사용하려면 러닝커브는 감수해야한다. 그것보다는 문서가 친절하지 않은게 더 큰 문제였다. 문서보다 구글링에 의지해야 하는 경우가 훨씬 많았다. 문법 때문에 막힐때는 현타 오기 일쑤였다. 프론트 개발하기 더 쉽자고 쓰는거인데, 이럴거면 express boilerplate를 사용하는게 낫지 않을까?
• 장점일 수도 있는 NoSQL의 특성은 NoSQL이 익숙하지 않은 나에게 카오스로의 초대장이었다. 모델이 꼬이면 쿼리도 꼬이고 스케일하기 오히려 어렵게 만든다.
• 복합적인 쿼리, 보안규칙에 한계가 있다.
• 마지막으로 firestore를 CMS 처럼 쓰기에는 콘솔 UI가 사용자 친화적이지 않다.

Prismic의 장단점

• Prismic과 같은 Headless CMS는 워드프레스와 달리 컨텐츠를 API로 제공한다. 데이터와 뷰를 완전히 분리하여 사이트 관리가 유연하다. 컨텐츠를 자주 업데이트하는 반면 뷰는 템플릿처럼 한번 개발하고 크게 변동이 없는 데브폴리오와 같은 거의 정적인 사이트에 딱이다.
• 나는 Prismic을 static site generator인 gatsby와 연계해서 사용한적 있다. gatsby에서 이 부분에 대한 플러그인이 잘 되어 있어서 개발에 큰 어려움은 없었다.
• 그러나 데이터를 체계적으로 관리하기에는 Prismic 대시보드의 UI가 직관적이지 않았다. UI만 봐서는 모델을 머릿속에 그려내기 어려운 점이 아쉬웠다. 블로그처럼 컨텐츠만 발행하는 용도라면 모델이 크게 상관 없겠지만 데브폴리오의 경우 향후 유저, 프로젝트, 댓글과 좋아요의 관계를 어떻게 설계할 것인지 등을 염두에 둬야 했다.

strapi를 선택하기까지

사실 두가지 서비스의 용도가 본질적으로 달라서 동일선상에 놓고 비교하기 어렵다. 나에겐 A부터 Z까지 내가 직접 백엔드 로직을 짤지 여부가 결정적인 고민 포인트였다. 데브폴리오는 기본적인 CRUD에서 커스터마이징이 많이 필요하지 않을 것으로 보여서 Headless CMS를 쓰기로 결정했다. 단 Prismic이 아닌 다른 서비스를 리서치 해보기로 했다. 그렇게 나온 옵션이 strapi와 contentful이었다.

To be continued...

토이프로젝트 모아보기 서비스 DevFoliOh! 구경하러 가기