DND 5기 3주차 - 백엔드 점검

 

디앤디가 시작한지 삼주가 지났다. 

나는 실무에서 개발을 하고 있긴 하지만 제대로 갖춰서 한 적은 없는 것 같다.

예를 들면 http 응답코드를 간소화해서 사용한다거나

git branch 전략을 알고는 있지만 굳이 feature branch를 따지 않는다거나.. 

사실 디비의 변수를 활용하면 최적으로 돌아갈걸 알고있음에도 시간이 없어서 서버단에서 가공한다거나..

와 이렇게 보니까 최악이네 나(ㅋㅋㅋ)

내가 이직을 결심하게 된 이유이기도 한 이런 주먹구구식의 개발을 하고있었는데

이번 사이드프로젝트가 규모는 작지만 좀 디테일한 부분들을 잡는다는 느낌으로 백엔드를 어떻게 꾸려갈지 백엔드 동료분과 이야기를 나누어 보았다.

 

일단 구체적인 요구사항이 나오지않아 디테일하게 이슈를 나눈다거나 하는 행위는 하지못한다.

앞단 없이 뒷단에서 할수있는 내용들을 정리해보았다.

 

1. 데이터베이스 구조

기본 요구사항에 맞는 데이터베이스 테이블을 설계하였다.

로그인을 선택사항으로 두고 비회원인 사람도 팀장이 되어 만남을 정할수있고 팀원으로 초대된 사람도 별도의 로그인 기능 없이 만남 내에서 스케쥴, 장소를 지정할 수 있다.

또한 약속을 잡을때 가장 잘 이용하는 채널인 카카오톡을 통해 로그인 할수있는 Oauth를 택할것인지 local을 통해 회원을 받을것인지 중에 추가기능은 로그인 OAuth를 채택할 지언정 기본은 local로 두기로 하였다.

그리고 아래는 데이터베이스 명세서를 쉽고 빠르게 가시화시켜주는 도구이다.

대학생분들과 협업하다보면 이런 정보들을 얻을수있어 좋다 헤헷

https://dbdiagram.io/home

dbdiagram.io - Database Relationship Diagrams Design Tool

기능 하나하나를 이야기하면서 함께 짜다가 시간이 오래 걸릴 것 같아 각자가 생각하는 테이블을 짜고 함께 설명하면서 교집합은 간결하게 넘어가고 차집합들중 좋은 방법을 함께 고민하여 함께 구조를 완성했다.

 

 

2. ORM 결정

 초반에는 js로 작업을 할 예정이여서 sequelize를 사용하려고 셋팅해놓았으나 중간에 ts로 변경이되면서 typeORM이 후보군으로 올라왔다. sequelize보다t typeORM이 속도가 살짝 더좋긴 하지만 ORM 자체가 속도가 느리기때문에 큰 이점은 못느꼇다. 또한 각 orm의 쿼리문 작성 방법이 typeORM이 조금 더 직관적인 느낌을 받았다.

 사실 sequelize가 좀 더 익숙하긴 하지만 typescript로 변환하는 과정이 필요하고 다른 백엔드분께서 typeORM의 경험이 있으셔서 셋팅하며 배워보기로 했다. typeORM으로 결정!

 

3. 그 외 고민들..

 - 서비스파일 어디에서도 컨트롤러의 뉘앙스가 나면 안된다는 조언을 받고 서비스파일에서 result template이 아닌 객체 형식으로 리턴해주기로 했다.

 - 현재 프론트단에서 맡아야할 작업들이 많이있는데 socket작업을 back단에서 해주어 넘겨줘도 프론트단에서도 핸들링해야되는데 이 부분에 너무시간을 빼앗기진 않을까.. 채팅이 아닌 팀원의 정보를 실시간으로 보는 용도이므로 선택과 집중이 필요한 순간인 것 같다. 프론트 단에 부하를 주지않고 백단에서 활용해볼수있는 것들은 cicd, docker 등 다양하기때문에 기술에 대한 선택과 집중이 필요할 것 같다.

 - 회원/비회원, 팀장/팀원 경우의 수가 조금 있어서 화면을 만들고 기능별 이슈정리 시 오류사항에 좀 민감하게 반응할 것 같다. 이 부분은 오류사항을 충분히 예측하고 기능별 이슈정리를 해야될것 같다.!

 - typeORM 에서 트랜잭션 코드는 잘 되어있으려나.. ts를 배우면서 과연 8주동안 내가 잘 완성 할수있을까 .. 

 

* OAuth kakao back process 

1. 프론트에서 백으로 카카오 유저아이디, 액세스 키를 쏜다
2. 백에서 그 유저가 쏜 정보를 갖고 실제 카카오 유저가 맞는지 검사한다
3. 이후 백에서 유저 정보를 가져와서 저장하고, 추가로 프론트에서 정보를 더 받는다면 처음에 키 받을 때 함께 받아서 가입 처리 후 저장. (소셜 종류, 해당 소셜의 유저 ID, 우리 서비스의 유저 고유 ID, 추가 정보 등 함께 저장)
4. 백에서 해당 유저에 대한 자체 토큰과 리프레쉬 토큰을 발급한다
5. 그 토큰을 가지고 우리 서비스를 이용하게 한다
6. 프론트에서 토큰 만료 시 우리 서버의 리프레시 토큰으로 토큰을 재요청한다

 

항상 나의 개발 치트키를 담당해주시는 처루님 감사