배경 기존의 PNU_Mail_Badara는 React 프론트엔드 + Nodejs 서버 + 이메일 전송 스케줄링을 오직 하나의 레포에서 담당했다. 아무래도 혼자서 개발하는 것이기도 했고, 빠른 디벨롭을 위해 굳이 레포를 나누어서 복잡성을 늘리기보다는 하나의 레포지토리에서 전부 관리하는 것이 편했다. 그러나 PNU_Mail_Badara 모놀리식 레포의 문제점은 "서버에서 하는 일이 너무 많다"는 것이었다. 1. React 프론트엔드 서빙 2. API 서버 3. 특정 시간마다 크롤링 + 이메일 전송 스케줄링 매일 특정 시간마다 스케줄링을 수행할 때, Koyeb(호스팅 서비스 플랫폼) 무료 플랜의 최대 메모리 사용량을 넘어가면서 배포 서버가 자꾸 셧다운되는 일이 발생했다.(참고: https://insengnew..
배경 23년 9월, MailBadara 구독 서비스를 처음 개발할 당시부터 생각했던 "모바일 앱" 개발에 들어갔다. 원래 23년도 겨울방학에 구현할 생각이었는데 예정에 없던 인턴을 하게 되면서 많이 밀렸다. 저번주부터 구상에 들어가 현재 초기 모델을 구현하는 중이다! 안 바빠서 개발하는 건 아니고, 이 이상 늦어지면 졸업과제가 할 게 너무 많아질 것 같아서 병행이 불가능할 것 같았기 때문에, 차라리 미리 해버리기로 마음 먹었다. MailBadara의 접근성 이슈 모바일의 구현은 항상 머릿속에 두고 있었다. 현재의 MailBadara는 학과 소식을 매일 특정 시간마다 이메일로 보내주는 뉴스레터이다. 직접 학과 홈페이지를 들락거리지 않아도 되고, 구독만 하면 알아서 새로운 소식을 알려주기 때문에, "쉽고, ..
한참 묵혀두고 있다가 일주일 전부터 디자인을 갈아엎기 시작했다. 빨리 배포하려고 디자인은 1도 신경 안 쓰고 개떡같이 만들긴 했지만, 만들고나서 내가 보기에도 너무 구렸다. 시험 기간도 겹치고 다른 일들도 겹쳐서 미루고 미루다가 2024년 신년을 맞아 뜯어고치기로 했다. 그렇다고 코드 리팩토링을 한 건 아니고 디자인만 리뉴얼했다. Background 내가 보기에도 정말 구리다. 밋밋하게 흰 배경은 하기 싫어서 react-particles라는 인터랙티브 배경 라이브러리를 써봤는데.. 좋은지는 나도 모르겠다.. 이번 리뉴얼에는 원래 하고 싶었던 우주 배경을 도입하기로 했다. Department 섹션 단순하게 테이블로 나열하기보다는 모바일 웹뷰에서도 보기 쉽도록 slider 방식으로 구현하고 싶었다. swip..
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보다 훨씬 빠르고 효율적..
