과연.. 이대로 괜찮을까?
요즘 동아리 CMC활동을 하고있는데.. 나랑 팀인 친구가 매우 잘하는 친구다.. 이 친구에게 아키텍처에 대해 배우고 동아리 프로젝트를 진행하면서 접목시키다보니까 구조가 진짜 중요하다는 생각을 하게 되었습니다..
대충 배운내용을 토대로 찍먹을 해보려고 한다.. 그렇기 위해선 우선 블로그의 컨셉을 정해야한다. 그 컨셉에 따라 사용방법이 다를 수 있기 때문이다.
우선 블로그는 정적으로 사용할 생각이다.. 블로그는 개인적인 블로그로도, 친구들과 같이 사용하는 블로그, 기술 블로그, 프로젝트 기록용 등 여러활용도 있게 사용할 수 있도록 개발할 생각이다.
추가로 notion과 연동하는 것인것 만큼 게시물 이외에 포트폴리오로도 활용할 수 있는 구조도 만들 생각이다. 많은 개발자들이 포트폴리오, 기술 블로그 등을 운영하기 유용하도록 하는것이 나의 개발 목표이다.
그렇기 때문에 만약 사용자가 있다면 사용자 입장에서 커스터마이징보다 notion만 활용해서 글을쓰고 그러는 경우가 대부분일 것이다. 하지만 아무리 생각해도 연산 속도가 매우 거슬린다.. api를 계속 호출하는게 맞을까? 근데 또 그렇다고 ssg를 활용해서 사용하자니 유저가 노션에 글을 쓸 때마다 build를 해줘야 하는 번거로움이 생기는거 아닐까?
어디서 듣기엔.. vercel에 배포된 프로젝트가 가끔 build를 해준다는 거 같은데 이건 좀 더 알아봐야 할 거 같다. 그렇기 때문에 초기엔 service - domain - api service의 형태로 구현을 고려하였다..
아키텍처를 세워보자
우리는 service를 통해 api 호출과 domain 설정, memory 설정을 진행한다. 대충 내가 생각한 플로우는
- service method를 실행할때 state manage를 먼저 확인해서 이미 불러온 데이터가 있는지 검증을 진행한다.
- 불러온 데이터가 있다면 state manage를 통해 데이터를 받아오고, 없다면 api service를 통해 api 호출 주로 get이겠지만.. 호출을 진행한다.
- 호출한 테이터를 state manage에 저장한다.
의 플로우를 지니게 될 것이다. 대충 그림으로 본다면 이러한 구조일 것이다.
이런 구조로 우선 개발을 진행할 생각이였다.
검증을 하자.
그럼 우리가 생각한 방식의 ssr 방식의 state manage를 사용하는 게 과연 더 좋다 할 수 있을까??
이러한 생각을 할 수 있다. 지금 당장 notion api를 활용해서 글을 긁어올때의 속도가 좋지 않다. 아직 제대로 배포환경이 아니라 잘 모르겠지만, 빠르지 않은건 확실한 것 같다.
그렇다면 이러한 문제가 생길 수 있다. 초기 진입 시점에 유저에게 매우 안좋은 경험이 될 수 있다. 연산이 많고, api 속도가 걸린다면 이것은 post등 컨테츠가 추가될때마다 계속해서 초기 진입 시점의 로딩 시간이 늘어날 것이다.
이러한 문제를 어떻게 해결할까..? 우선 지금의 연산처리는 속도를 좀 먹는 것으로 보인다. 쉽진 않겠지만, 속도를 잡아도 블로그의 특성상 게시글이 계속 늘어날거고 지금의 api 호출은 당연히 계속 느려질 것이다. 이러한 구조가 과연 좋다고 할 수 있을까?? 음..
그럼 다른 방법은 ssg의 방식을 사용하는 것이다.. 블로그는 속도가 생명이라 생각한다.. 그럼 만약 ssg로 빌드시 모든걸 저장한다 가정했을때, 신규 포스팅은 어떻게 캐치할 수 있을까..?
이걸 찾는게 나의 숙제다… ㅎㅎㅎ…. 못찾으면 뭐.. ssr의 방식의 속도 부하 테스트를 해야겠지.? 개발 종료 시점 전에 찾을 수 있으면 좋겠다.. 쨋든.. 주저리 주저리.. 쓰긴 했지만.. 이 프로젝트는 꼭 끝까지 가길..