비밀일기를 완성하고 싶었는데, 프론트 작업이 상당히 미뤄질 것 같아서
잠깐 접어놓고 많은 사람들이 만들어본다는투두리스트를 만들어보기로 했다.
프로젝트를 왜 하는데?
굳이 프로젝트라는 것을 하는 것은 두가지 이유가 존재한다.
1. 이력서 상에 팀 프로젝트는 6월 10일에 끝났는데, 적을 수 있는 것이 없다.
블로그를 읽어보면 꾸준히 공부를 했구나. 라고 알겠지만 수많은 이력서를 열람하면서 블로그까지 들여다보지 않을 것 같았다.
그래서 한개를 더 적기 위해서 토이 프로젝트를 해야겠다고 생각했다.
2. 수료 이후 공부를 하면서 배웠던 것들을 녹여내보고 싶었다.
팀프로젝트의 코드는 쉽사리 건드릴 수가 없었다, 이미 데이터도 다 들어가있었고 프론트쪽도 작업을 정리했기에.
그렇지만 취업준비를 하면서 다뤄보지 못한 것들을 써보고 싶었고, 그것을 내 코드에 증명하고 싶었다.
써보지 않았던 REST API도 쓸 수 있게 됐고, 테스트 코드를 작성하는 것도 가능하게 됐다.
코드에 가독성에 대하여 조금 더 고민해볼 수 있었고, 스택만 화려하게 사용하는 것이 아니라 적은 스택으로 최대한의 성과를 뽑고 싶었다.
그리고 나의 의지로 공부해서 사용했다고 이야기를 하고 싶었다.
이걸 왜 썼나요? 라고 했을 때 커리큘럼에서 배워서요 라는 말이 아니라
이런 기술이 있는데 사용하면 좋을 것 같아서 공부해서 써봤습니다. 라는 말을 하고 싶었다.
이러한 이유로 토이 프로젝트를 해야겠다고 생각했고
때마침 같이 작업을 하겠다는 프론트분이 계셔서 타이밍이 좋다고 생각해서 작업을 해보려고 한다.
내가 생각한 요구사항
- 상호교류가 없는 개인만 사용하는 어플리케이션
- 상호교류가 가능하도록 확장성을 생각하며 작업을 하긴 할 것이다.
- 일간, 주간, 월간 단위로 투두를 입력할 수 있다.
- 장기간 혹은 특정 일자를 지정해서 입력하는 것도 허용할 것이다.
- 카테고리 분류가 가능하며 그 하위에 할 일을 적을 수 있다.
- 카테고리는 아무것도 지정하지 않았다면 일반이라는 이름으로 제공된다.
- 해야하는 일을 했다면 터치 한번으로 체크를 할 수 있다.
- 메모 기능도 같이 있으면 좋겠다!
- 한 일과 하지 않은 일을 n/m 의 형식으로 해당 날짜를 누르지 않고도 상단에서 볼 수 있다.
- n/m의 형식이 좋을지, 그냥 한 것만 카운트할지는 생각을 해보는게 좋을 것 같다.
DB 모델링
각 테이블 별 사용목적
- user | 유저의 정보에 위한 테이블
- id : PK로 사용, 정보 생성 당시 UUID로 자동 입력
- email : 로그인을 하기 위한 ID로 사용, 인덱스 & 유니크 적용
- password : 비밀번호는 자동으로 암호화되서 저장함
- name : 투두리스트 최상단에 ㅁㅁ님의 투두리스트를 표기하기 위한 컬럼
- createAt : 계정 생성 날짜, 자동 입력
- updateAt : 계정 정보 수정 날짜, 자동 입력
- category | 카테고리를 분류하기 위한 테이블
- id : PK로 사용, 정보 생성 당시 UUID로 자동 입력
- fk_user_id : FK로 사용, 카테고리 생성시 식별을 하기 위한 컬럼
- name : 카테고리에 보여질 이름을 표기하기 위한 컬럼
- task | 테스크의 정보를 위한 테이블
- id : PK로 사용, 정보 생성 당시 UUID로 자동 입력
- fk_category_id : FK로 사용, 테스크 생성시 식별을 하기 위한 컬럼
- content : 내용을 표기하기 위한 컬럼
- createAt : 테스크 생성 날짜, 자동 입력
- updateAt : 테스크 정보 수정 날짜, 자동 입력
- expiresAt : 테스크 만료 날짜, 사용자가 입력
- status | 테스크의 일일 상태를 확인하기 위한 테이블
- id : PK로 사용, 정보 생성 당시 UUID로 자동 입력
- fk_task_id : FK로 사용, 테스크의 일일 상태를 식별하기 위한 컬럼
- createAt : 생성이 되었을 경우, 해당 날짜에 테스크가 완료된 것을 표기위한 컬럼
고민이 있긴 한데, 여기서 어떻게 가는 것이 더 좋을지 모르겠다.
한번에 장기간의 날짜를 입력 한 후 매일 체크를 하기 위해서 status 테이블을 아예 빼버렸는데,
이것이 나를 어떻게 괴롭힐지 예상이 되긴 한데...
고민을 하면서 더 좋은 것이 있다면 구조도 바꿔보려고 하기에 다른 분들이 만들어놓은 ERD를 많이 참조해봐야 할 것 같다.
사용 스택
Frontend : React
Backend : NestJS, REST API
Deployment : Google Cloud Platform
왜 또 NestJS?
당연히 express를 써보는 것이 좋다고 생각은 하고 있다.
하지만 프레임워크를 선택함에 있어서 제일 중요한 것은 생산성이라고 보고 있는데
기존의 코드를 보면서 배우는 것에는 무리가 없겠지만 처음부터 express로 서버를 구축하는 것은 생산성이 나쁘다고 생각했다.
제대로 다뤄보지 못해서 서버구축에 불확실성이 있다면, 굳이 선택을 해야할 필요가 없다고 봤다.
언어의 한계, 아키텍처의 한계로 인한 문제가 전혀 없기에 더 많이 사용을 해봤고 익숙한 것이 좋다고 봤다.
고려해봐야할 사항
테스크 한개를 불러오기 위해서는 검증해야하는 것이 상당히 많은데
이것을 어떻게 DB에 부담 없이 가져올 수 있을지
한달의 리스트같은 것을 가져올 때 긁어야하는 사항이 너무 많아서 생각을 좀 많이... 해봐야할 것 같다!
