dev'log 2주일 회고

2023년도 8월 25(금)부터 8월 31(목)까지 dev'log 를 개발하면서 현재 겪고 있는 문제들에 대해서 작성하면서 한 번 더 고민하는 시간을 갖고자 블로그를 작성하고 있습니다.

생각하는 개발자

개요

git commit 을 즉시 가져오는 것은 비용적으로 좀 힘들것이라 판단했습니다. 일단 생각하고는 있는 걸로는 저 혼자만 사용하려는 목적으로 개발하고 있지만, 혹여나 사용자가 500명만 넘어도 꽤나 힘들것 같다는 생각을 하게 되었습니다.

(사실 지금 테스트하는 현재도 성능상으로 불안불안합니다.)

그래서 NestJS의 Scheduler Task로 Cron을 지정해주어 background에서 동작하도록 한다면 특정 시간대에만 갱신되기에 무리를 최대한 줄일 수 있으리라 생각했습니다.

 

헌데, 이러한 일련의 과정을 처리하는 데에 가장 큰 문제가 발생할 수 있다는 것을 알아냈습니다.

애플리케이션(dev'log)는 git commit의 정보를 알 수 있는 방법은 github api를 통해서 가져와야만 한다는 점이었습니다.

(현재 github에만 올려진 repository에 대해서만 정보를 가져오는 형태)

그렇기 위해서는 토큰을 알아야한다는 가장 큰 문제가 발생했습니다.

 

사실 이 영역이야말로 이 프로젝트의 핵심과도 같은 영역이기에 고민을 현재 상당히 많이 하고 있습니다.

 

고민

방법을 3가지 정도 떠올리긴 했습니다.

• 데이터베이스에 토큰을 넣어버린다. 양방향으로 암호화해서 실제 사용할때만 복호화한다.
• 유저가 로그인하고 나서 1시간 주기로 Scheduling을 통해 작성하도록 하고, 약 8시간간 지속하도록 한다.
• web hook을 사용하여 큐에 담아두었다가 특정 주기마다 작성하도록 한다.

첫 번째 방식 같은 경우에는 그냥 무식하게 데이터베이스에 넣는 방식으로 가장 단순하게 구현할 수 있지만, 데이터베이스의 값을 관리자가 확인 가능하다는 점에서 사용할 수 있다는 위험과 동시에 토큰은 따로 관리할 필요가 없어서 유용하다는 큰 장점을 포기하게 됩니다.

 

두 번째 방식은 유저가 가장 최근 접속되어있던 시간만큼만 토큰을 따로 보관하고 있다가 삭제시키는 방식입니다.

시간 제한 등을 두어 알아서 사라지게 하면 그만이기에 꽤 유용한 방법이라고 생각이 듭니다.

 

마지막 세 번째 방식은 github에 있는 web hook을 통해서 push가 감지가 되면 서버에게 변경됨을 알리고 블로그를 자동으로 작성하도록 하는 방식이다. 가장 유연하게 대처할 수 있는 방식이지만, 사용자가 일일이 설정해주어야한다는 치명적이라면 치명적인 문제가 발생한다. 사실 위 2가지 방법보다야 훨씬 괜찮은 방법이라고 생각이 든다.

 

회고

9월 2일까지 열심히 조사해서 github web hook보다 더 좋은 방법이 있다면 그 방법과 비교해서 더 괜찮은 방법을 택하고, 개발에 몰입할 생각입니다. 만일 github web hook을 하게 된다면 어떻게 해야하는 지 역시 조사를 할 필요가 있어보입니다.