본문 바로가기

Project

[간단한 퀴즈 서비스] Day09~11 DB설계 및 구현

 퀴즈 문제까지는 미리 문제 세트를 정리해 둔 엑셀파일 읽어서 서버 메모리에 올려서 쓸 수 있었지만 퀴즈 결과를 저장하고, 랭킹을 계산하는 부분에서 계속 메모리에 두고 쓰는 건 서버를 내렸다 켜면 데이터가 사라지기에 데이터의 일관성이 없어서 문제였다.

FE, BE에서의 빠른 피드백과 개발을 위해 DB 없이 API를 구성하였는데 더 이상을 로컬에서 개발할 때에도 매번 회원가입, 퀴즈 풀고, 랭킹 확인하고 하는 작업을 반복해야 하는 단점이 있어서 개발속도 측면에서도 지장이 생겼다.

미루어두었던 DB 설계와 구현을 하기로 하였다.

 

고려사항

어떻게 해야 추후에 했던 작업 또 하지 않고 유지보수 및 기능 확장에 드는 시간을 줄일 수 있을까?

어떻게 만들어야 확장성을 생각할 수 있는가

어떻게 만들어야 중복을 제거할 수 있을까?

 

여러가지 고민이 있었고 DB 항목이 다시 바뀔 수 있다 생각 들었기에 DB 없이 JS Map 객체를 이용해서 메모리이 임시적으로 quiz, user, score 정보를 담아두었다.

 

 문제점으로는 메모리에 담아두었기에 서버를 내렸다 올리면 리셋되었다.

파일에 저장하고 읽어오는 방식으로 임시 구현하려 하였으나 node의 process를 이용해서 서버 종료, 예기치 못한 종료했을 때 동작하게 하는 함수는 하나만 등록 가능하였다.

 

나의 경우 모듈로 user, score를 분리하였기에 둘 다를 등록하여서 처리하는 경우, 서버 종료 이후 둘 중 하나만 저장되는 등 의도대로 되지 않았다. 두 모듈을 하나로 합칠 수도 있겠지만 서로 다른 성격이라 합치고 싶지 않았다.

 

 원래 의도는 DB없이 api 구현해서 결과 값 전송만 프런트에서 요청했을 때 바로 받아볼 수 있게 끔 하고서 DB를 쓰는 버전으로 리팩터링 하려 하였었다. 하지만 메모리 버젼의 휘발성으로 인해 테스트 할 때마다 회원가입→로그인 → 그 다음 작업 을 하는 식으로 불필요한 테스트 시간이 늘어나서 더 이상은 그 시간을 비용으로 쓰고 싶지 않았다. 아직 절반 가량만 동작 되게 하였지만 바로 DB 설계와 database, table 생성을 하였고 회원가입 로직부터 리팩터링을 시작하였다.

 

 깔끔하게 정리된 다른 프로젝트 레포지토리를 참고하였고 그 방식을 따라서 sql문의 경우 src/queries/[Resource] Query.js 형식으로 모아두었다.이 부분도 결국 SQL injection에 대한 문제가 있을 수 있어서 ORM으로 작성하는 게 좋지만 추후에 ORM 버젼으로 리팩터링 하기로 하고 우선 현재 DB 없이 동작만 되게 구현하였던 회원가입, 아이디 중복확인, 로그인 부분을 DB 버전으로 리팩터링 하였다.

 

 로그인을 다시 만들며 부족한 부분들이 더 보인다.

error 처리, 로그인 여부를 확인하는 미들웨어, /auth에 대한 별도 api, jwt 토큰을 1개만 쓰고 시간은 10분으로 두었는 데 적절한 인증, 인가 정책의 필요성, 현재 routes, controllers 로만 분리해서 쓰고 있는데 services까지 추가하여 유지보수성을 늘려야겠다는 생각 등등 해야할 것들이 점점 더 보인다.