Lets Git It

1. 기획
2. 초기 세팅 단계(백) ✅
3. 서비스 로직
4. 배포 과정
5. 회고 및 앞으로의 운영

기획의 큰 툴이 짜여진 이후 드디어 본격적으로 백엔드만의 업무가 시작되었다.

로직을 시작하기 이전 우리가 가장 중요한 게 여겼던 것은 크게 3가지로 나뉘어 지는 것 같다.

1. 기술 스택 선택
2. 첫 업무 분배
3. API 업무 분배

백엔드 준비 및 초기 세팅

기간 : 2023년 1월 18일 ~ 2023년 1월 27일

📋 기술 스택 선택

✏️ 언어 (TypeScript vs JavaScript)

언어는 너무나 당연하게도 3명 모두 TypeScript를 선택했다.

타입스크립트의 유명세가 점점 늘어난 것도 있지만, 가장 큰 원인은 우리 3명의 백엔드 모두 자바스크립트의 단점을 명백히 알고 있기 때문이다.

하지만 장점과 단점이 있음에도 타입스크립트를 정한 데에는 유명세가 가장 컸다.

최종 결정 : TypeScript

✏️ Framework (Express vs NestJS)

사실 이 부분에 대한 의견은 조금 갈렸다.

NestJS와 Express간의 차이가 명백히 있었지만 사실 우리의 서비스는 Express에서도 충분히 돌아 갈 수 있었기 때문에 NestJS를 택할 이유는 현재 이 프로젝트 수준에서는 명확히 짚어내기가 쉽지 않았다.

심지어 Express는 이전 부트캠프 당시 2번이나 진행했었던 프레임워크이기 때문에 생소함이 적었고 프로젝트 하는데에도 거침이 없을 것 같다는것이 공통 의견이었다.

그럼에도 불구하고 NestJS를 선택한 이유는 다음과 같다.

1. 명백한 CRUD : NestJS는 구조가 갖혀져 있는 만큼 CRUD하나 만큼은 다루기가 너무나 편하다.

2. TypeScript와의 완벽한 호흡 : NestJS는 타입스크립트와 완벽한 호흡을 자랑하고 있다. 그렇기 때문에 전반적으로 타입 스크립트를 공부하고 있는 우리들에게 있어 안성맞춤인 프레임워크다.

최종 결정 : NestJS

✏️ DataBase와 ORM

이것 또한 만장 일치로 빠르게 결정되었다.

백엔드로서의 최종 목표는 CI/CD에 대한 경험과 배포된 서비스의 운영이었기 때문에 새로운 DB를 학습하는 것에 대한 부담감을 줄이고 싶었고 부트캠프 당시에는 ORM을 DB CONNECTION 하는 것에만 쓰고 나머지는 로우 쿼리를 사용했기 때문에 ORM에 대한 학습도 어차피 필요하여 DB는 MySQL로 유지하고 TypeORM을 조금 더 깊이 다뤄보자는 목표를 유지하였다.

최종 결정 : MySQL & TypeORM

📋 첫 업무 분배

업무 분배는 가볍게 사다리 타기로 이루어졌다.

세 명이서 사는 지역이 너무 달라 오프라인 모임은 쉽지 않기 때문에 어느정도 의견이 공유된 시점이다 보니 실행만 하면 된다.

그렇게 해서 총 3가지 파트로 나뉘어졌다.

1. LSM님 - ERD 설계
2. JSH님 - NestJS 초기 세팅 (Github 레포 생성, 프로젝트 템플릿 생성, DB Connection)
3. OHS(나) - API 엔드포인트 설계

파트를 나눈 후, TypeScript에 대한 전반적인 공부 및 NestJS에 대한 학습 기간을 설날 포함해서 1주일 정도 잡았고 공통으로 Github의 REST API를 공부하여 어떤 지표를 써서 어떤 식으로 점수화 할 것인지에 대해서 생각해보기로 했다.

✏️ 깃허브에서 가져와 점수화 할 수 있는 지표

우선 깃허브 관련 지표는 사진에서보는 바와 같이 총 14개로 결정하였고 각 각의 지표에 중요도를 우리만의 방식으로 계산하여 반영하기로 결정했다.

참고로 현재의 점수 로직에는 약간 문제가 있다, 총점이 정해져있지 않고 우리만의 수치화이기 때문에 한 쪽에 쏠릴 수 있는 경우가 나타날 수 있다. 추후 사람이 많아지고 어느정도의 데이터가 모여지면 점수 체계활르 바꿀 계획에 있다.

✏️ ERD 설계

ERD 테이블

지표가 정해짐에 따라 ERD를 생성하였고 크게 3파트로 나눌 수 있다.

1. 회원가입한 유저

2. 커뮤니티 서비스

3. 깃허브 지표 및 랭킹

✏️ NestJS 초기 세팅

NestJS는 역시 Express와는 다르게 강력한 Cli기능이 있어 손쉽게 템플릿 설정 및 MVC 패턴을 적용할 수 있었다.

별 다른 문제 없이 패스!

✏️ API 엔드포인트 설계

엔드포인트 설계도 어렵지 않았다.

내가 담당하게 될 5가지의 API를 포함해 총 30개 정도의 API를 생각해낼 수 있었고 나머지는 기능이 추가됨에 따라 구현하기로 했다.

✏️ 깃허브 API의 한계....

이것 때문에 사실 좀 이슈가 많았다.

1. 깃허브 API는 PERSONAL ACCESS TOKEN을 발급 받은 자에 한해 1시간당 5000번 요청 가능
   => 처음에는 우리가 직접 깃허브에서 모든 유저의 정보를 가져와 시간단위로 갱신을 하면서 랭킹을 세우려고 하였지만 1명 당 14개의 지표를 요청, 100명만 넘어도 1400번...하나의 토큰에는 한계가 있었고 팀원 전부의 토큰을 사용한다고 해도 35,000번이란 한계가 있어 기획을 변경하였다. 유저가 직접 검색 창에 깃허브 유저를 입력하는 것으로 랭킹 등록을 로직을 실행하게끔 유도.
2. 우리가 선택한 지표 중 스폰서 관련 API가 없어..다른 한 유저가 UNOFFICIAL로 만든 외부 API를 사용하였다.

어쨌든 처음에 기획한 의도와는 많이 틀어졌지만 그래도 아직까지는 나름 매력적인 프로젝트라는 생각이 들었고 계속해서 진행하기로 했다.

📋 API 업무 분배

세상 그 무엇도 사다리 타기보다 공평한 것은 없다.

ERD를 기준으로 총 3파트로 분배하기로 했다.

1. 회원가입 및 로그인 그리고 댓글과 대댓글 CRUD (10개)

2. 커뮤니티 서비스 글쓰기 CRUD (11개)

3. 서비스의 꽃꽃꽃!!! 메인 로직 (6개)

내가 3번을 강조하는데에는 이유가있다....바로!! 내가 담당한 로직이 3번이라는 것...

사실 가장 하고 싶었던 것은 1번과 2번이었다. 1번에는 깃허브 OAuth를 사용한 로직에다가 보안 관련 이슈를 조금 더 생각할 수 있기 때문에 매력적이었고, 2번은 S3를 사용할 수 있는 기회여서 매력적이었다. 3번도 매력적이긴 했다만 뭔가 외부 패키지를 다양하게 쓰는 것을 체험하고 싶어서 아쉬웠다.

하.지.만. 서비스의 중축임 메인 로직을 담당하고 있다는 것이 마음 부담이 컸지만 그만큼 기대가 되었기 때문에 불만은 없었다. 오히려 내가 다른 팀원들을 지체시킬까봐 걱정만 가득했다.

이제..다음 게시글에서 본격적으로 내가 작성한(아직은 엉성한 티가 빡빡나는) 로직에 대해 일부 작성해보려고 한다.