배경 기존의 PNU_Mail_Badara는 React 프론트엔드 + Nodejs 서버 + 이메일 전송 스케줄링을 오직 하나의 레포에서 담당했다. 아무래도 혼자서 개발하는 것이기도 했고, 빠른 디벨롭을 위해 굳이 레포를 나누어서 복잡성을 늘리기보다는 하나의 레포지토리에서 전부 관리하는 것이 편했다. 그러나 PNU_Mail_Badara 모놀리식 레포의 문제점은 "서버에서 하는 일이 너무 많다"는 것이었다. 1. React 프론트엔드 서빙 2. API 서버 3. 특정 시간마다 크롤링 + 이메일 전송 스케줄링 매일 특정 시간마다 스케줄링을 수행할 때, Koyeb(호스팅 서비스 플랫폼) 무료 플랜의 최대 메모리 사용량을 넘어가면서 배포 서버가 자꾸 셧다운되는 일이 발생했다.(참고: https://insengnew..
배경 23년 9월, MailBadara 구독 서비스를 처음 개발할 당시부터 생각했던 "모바일 앱" 개발에 들어갔다. 원래 23년도 겨울방학에 구현할 생각이었는데 예정에 없던 인턴을 하게 되면서 많이 밀렸다. 저번주부터 구상에 들어가 현재 초기 모델을 구현하는 중이다! 안 바빠서 개발하는 건 아니고, 이 이상 늦어지면 졸업과제가 할 게 너무 많아질 것 같아서 병행이 불가능할 것 같았기 때문에, 차라리 미리 해버리기로 마음 먹었다. MailBadara의 접근성 이슈 모바일의 구현은 항상 머릿속에 두고 있었다. 현재의 MailBadara는 학과 소식을 매일 특정 시간마다 이메일로 보내주는 뉴스레터이다. 직접 학과 홈페이지를 들락거리지 않아도 되고, 구독만 하면 알아서 새로운 소식을 알려주기 때문에, "쉽고, ..
1차 서버 리팩토링 후 배포하니 문제가 발생했다. 계속해서 똑같은 정보를 담은 메일이 반복해서 전송되는 문제이다. 전송받은 게시물이 중복되지 않도록 DB에 게시물 인덱스를 저장하는데, 여기서 문제가 발생했다. 슈팅 원인 // server/src/types/UserType.ts export interface UserType { email: string; latest_post_indexes: number[]; // here! department_code: string; subscribe_time: Date; } 기존 유저 테이블에는 latest_post_indexs인데, 리팩토링하면서 latest_post_indexes으로 바꾼 것이 문제였다... 허무하게도 변수 이름을 원래대로 고치니 해결됐다. 메일 전송..
Migration 그동안 미루고 미루었던 서버 리팩토링을 진행하기로 했다. 그 과정을 기록한다. 이슈 현재 MailBadara 서버의 문제는 바로, 구독자들에게 뉴스레터를 전달할 때 순간적으로 메모리 사용량이 튀어서 Koyeb(호스팅 플랫폼)의 무료 플랜 메모리 오버로 프로세스가 강제로 종료된다는 것이다. Koyeb에선 프로세스가 죽을 때 즉시 재실행시켜주기 때문에 메일 전송 로직은 완료되기는 한다. 끝날 때까지 몇 번 씩 프로세스가 죽을 뿐.. 서비스가 작동"은" 해서 로직을 더 이상 수정하지 않고 이 상태로 배포하고 말았는데, 한 달이 지난 지금. 더 이상 미룰 수 없다 생각했고 진행 중이다. 슈팅 이를 해결할 방법은 2가지다. node에서 bun으로 migration node보다 훨씬 빠르고 효율적..
배포 이제 그래도 사람들이 봐줄만하게는 만들었기에 베타 테스트를 진행해보고자 했다. 그러나 사람들에게 배포하기 위해서는 서버를 개설해야 했고, 돈이 드는 유료 모델은 싫었다. AWS EC2의 프리티어는 진작에 써버렸고 vercel의 프리티어도 저번 해커톤에서 사용해버렸다. 이곳저곳 무료 호스팅 서비스를 찾아보다가 koyeb을 발견했고 기간 제한 없이 최저 스펙의 프리티어 서버를 무료로 사용할 수 있었다. 첫 베타 테스트 10월 3일 오후 12시부터 10월 6시 오후 6시까지. 학술 동아리 사람들을 대상으로 베타 테스트를 진행했다. 목표가 학교 전체를 대상으로 하는 만큼 사전에 철저하게 버그를 잡기 위해 먼저 소규모로 배포했다. 다행히 별 문제없이 베타 테스트를 마쳤고 피드백을 들을 수 있었다. 피드백 1..
