알파플라이 개발일지

기술매니저님 면담 질문

알파플라이 — Wed, 20 Jul 2022 19:17:08 +0900

실전 프로젝트 종료가 약 2주 남짓,

지원 주차만 남기고 있는 지금 공부할 우선순위가 궁금합니다.

주로 면접에서 대답할 수 있어야 할 부분에 대해서, 어떤 부분에 포커싱할지?

1. 현재 실전프로젝트에서 적용한 기술 및 라이브러리

- 내 파트 위주로 잘 알고 있으면 될 것인가? WebRTC, socket.io 및 일부 API의 알고리즘들

- 현재 우리 조 BE는 각자 실력이 좋아서 분담이 확실함, 손대지 않은 부분에 대한 공부를 해둬야 하는지?

- JS로 작성한 코드는 모두 알고 있지만, 다른 팀원이 해결해준 인프라에 대한 지식이 부족함.

DB 세팅(MySQL), Redis, CI/CD(github Action), Test code 등에서 빈약함.

2. CS 공부

- 쉽게 배우는 운영체제

- IT 엔지니어를 위한 네트워크 입문

- 데이터베이스 개론

3. JavaScript 자체

- 모던 자바스크립트 Deep Dive

- 코어 자바스크립트

- 외부 강의를 통한 클래스, 비동기의 이해

4. 알고리즘 스터디 자체의 중요성? 코딩 테스트?

- 코딩 테스트 대비?

항해99 실전프로젝트 2주차 WIL

알파플라이 — Sun, 10 Jul 2022 17:28:30 +0900

1) 영상채팅 기능의 추가 / 보완 및 인터뷰 예약 관리 시스템과의 연결

영상채팅 기능에 텍스트 채팅 추가 (WebRTC + socket.io)

- socket.io 코드를 WebRTC 연결을 위한 시그널링 파트와 텍스트 채팅 파트로 구분하고 주석 처리하여 다른 팀원도 이해할 수 있게 작성해둠

영상채팅방 입장시, 서비스의 "인터뷰 예약 기능"을 통해 생성되어 DB에 저장되어 있는 interview code를 입력해야만

영상채팅방이 생성되어 입장할 수 있도록 변경, 알맞은 인터뷰코드의 경우에도 인터뷰 예약시간 15분전 ~ 3시간 후에만 입장이 가능하도록 변경

- 별도로 운영하고 있는 영상채팅 서버에 MySQL DB를 연결함.

인터뷰 종료 버튼을 추가하여, 인터뷰에 참여한 양측 사용자가 모두 인터뷰 종료에 체크하면 해당 인터뷰 건의 status를

"지원서 접수"에서 "인터뷰 완료"로 변경할 수 있도록 상태 관리 기능을 추가함.

- MySQL DB의 인터뷰 예약 및 관리 테이블인 "application" 테이블에 상태관리 기능을 적용한 것.

2) 회원관리 / 프로젝트 게시글 / 자기소개 게시글 API 트러블 슈팅

- 모든 코드를 테스트하고 각 기능을 맡은 팀원과 함께 수정 및 보완사항 공유

- 특히 mongoDB에서 MySQL로 이전하면서, 특정 API의 경우 join 관계에 있는 데이터들을 모아 보냄에 따라 API response의 데이터 형태가 변화했음. 객체와 배열이 복잡하게 중첩되어 있는 데이터가 생성됨.

- 이 데이터 형태를 본래의 API 문서에 적어뒀던 response 형태와 같이, FE가 활용하기 쉬운 단순한 형태로 가공해주는 코드를 작성하여 해당 기능을 사용하는 팀원들에게 공유함. 객체 리터럴 및 배열 메소드의 활용으로 간단하게 해결하였음.

3) 이메일 발송 코드 작성

- 서비스 내에서 사용자가 특정한 프로젝트에 인터뷰를 신청하거나, 본인이 작성한 프로젝트에 대한 인터뷰 요청을 받거나, 자기소개를 작성한 개발자에게 인터뷰를 제안하는 경우에 이메일을 발송해 알리기로 하였고 이에 해당하는 코드를 작성하였음.

- SMTP 서버의 연결 / SMTP 정보는 환경 변수로 은닉 / 이메일을 보내는 각각의 경우에 따라 다른 정보를 담을 수 있도록 html로 template 작성 / 각각의 template 작성기능 및 실제 이메일 발송기능을 모두 함수화/모듈화하여 메일 활용이 필요한 API에서 호출해 사용할 수 있도록 작성함.

4) 해결해결중인 문제 : 502 Bad Gateway

- 영상채팅을 적용한 EC2 서버에서, 아직 파악하지 못한 원인으로 502 Bad Gateway 에러가 발생하는 현상.

- 항상 일어나는 에러가 아니라, 서버가 잘 돌아가다가 수시간 만에 한 번씩 502 에러가 발생하고 접속이 되지 않는 경우라 원인 파악에 어려움을 겪고 있음. 502 에러가 발생하고 나서 pm2 서비스를 중단했다가 다시 켜기만 해도 아무 이상 없이 몇 시간씩 돌아가다가, 다시 502 에러가 발생함. 약 10시간~ 13시간 주기로 끊기는 것 같음.

- Node.JS의 idle timeout 시간과 AWS ALB의 기본 timeout 시간이 달라서 발생하는 문제로 생각하고, node.js 서버에 keep AliveTimeout 시간을 길게 설정해 보았으나 10여시간 이후 또다시 502 에러가 발생함.

- 시도할 부분: 일단은 ALB의 문제로 예상되므로 로드 밸런서의 log를 상세하게 확인할 수 있는 방법부터 알아볼 예정.

- 해결: 원인은 MySQL DB connection leak. DB 와의 소통이 일어난 후에는 반드시 DB 연결을 종료해주어야 했고, DB연결-쿼리를 통한 상호작용 - DB 연결종료를 더 쉽게 처리하기 위해 sequelize의 pool을 이용했음. 이것으로 502 에러는 더 이상 없음.

항해99 실전프로젝트 1주차 WIL

알파플라이 — Sun, 3 Jul 2022 21:12:53 +0900

키워드: 실전 프로젝트를 진행하며 기술적으로 막혔던 부분은 무엇인가요? 해결했다면 어떻게 해결했는지 과정을 작성해주세요!

이번 주차에 목표한 것

내가 분담한 기능 : WebRTC로 1:1 영상통화를 구현하는 것.

BE 팀원 모두 함께하기 : MySQL의 이해

기술적으로 막혔던 부분들 및 그 해결

1) socket.io / WebRTC

항해99를 진행해오면서 기존에는 REST API를 활용하여 다양한 기반을 구현했는데

WebRTC를 사용한 영상통화를 구현하기 위해 필요한 것은 socket.io 와 WebRTC에 대한 이해였음.

해결: 검색과 외부 강의를 통해 socket.io, WebRTC의 생소한 구조와 문법을 새로 익히는 데에 시간을 소요하였음.

2) https, STUN/TURN 서버

"socket.io에 의해 시그널링 한 후, WebRTC로 Peer-to-peer 영상통화가 가능하게 한다"

이것을 구현한 코드 예제를 수도 없이 찾아서 이해하고 실행해봤지만,

시그널링까지는 되는데 상대방의 영상을 받아올 수 없는 문제가 계속되었음.

해결1 : WebRTC에 의한 미디어 스트림 교환은 https 환경에서만 가능하다는 것을 알게 되고

해당 설정을 AWS에서 완료하였으나 그래도 같은 현상이었음.

해결2: STUN 또는 TURN 서버에 의한 문제라고 판단하고,

- 우선 확실히 이 부분의 문제인지 확인하기 위해 일부무료-일정사용량 이상 유료인 TURN 서버 서비스를 이용해봤음.

- 그 결과 정상적으로 영상이 교환되었기에, 조금 더 시간을 투자하여 자체 TURN 서버를 구축하여 해결함.

3) MySQL

BE 팀원 전원은 항해99로 코딩에 입문한 입장으로, 기존까지 항해99의 강의에서 학습한 mongoDB만 사용해왔음.

그러나 RDB + ORM 사용이 반드시 필요하다고 여겨, 프로젝트의 진행과 동시에 학습하여 적용하기로 함.

현재 기본 쿼리를 이해했고, mongoDB에서 배열/객체를 하나의 필드에 담아 사용하던 문제를

관계형 DB에 맞는 ERD를 설계해서 해결해야 하며(*임시로, JSON stringify와 parse를 활용하여 역정규화)

raw query를 사용하기보다 Sequelize 등의 ORM을 사용하기 위해 공식 문서를 리뷰하는 중.

해당 기능의 추후 목표

- 영상의 Audio에 하울링, 에코가 심하여 이 부분을 해결해야 함.

- 영상통화에 입장하는 방식을 보다 세련되게 개선할 예정.

- 영상통화와 텍스트 채팅이 동시에 이루어지도록 코드를 수정하고, CSS 적용을 위해 FE 팀원과 협업할 것.

항해99 7주차 WIL : 이번 주차 가장 신경 쓴 부분/기술

알파플라이 — Sun, 26 Jun 2022 11:51:10 +0900

7주차 클론코딩: AirBnB

가장 신경 쓴 부분

FrontEnd 작업이 수월할 수 있도록 API 문서를 정확히 작성하고, API를 최대한 빨리 완성하며, FE 요구사항에 맞춰 API를 수정하는 것.

기술

새로운 라이브러리나 모듈을 사용하지 않음. JavaScript라는 언어 자체의 숙련도를 높이고 싶었음.

1. 배열과 객체의 활용.

2. 가독성 있는 코드를 작성하는 것.

1) 변수명 신경써서 결정

2) 배열 메소드의 숙지를 통해 반복문과 조건문의 사용을 자제하고

3) 코드의 일정 단위별로 주석을 작성함.

220623 리더/부리더 온보딩 세션

알파플라이 — Thu, 23 Jun 2022 14:28:44 +0900

리더/부리더 온보딩 세션

* 실전 프로젝트 진행에 대한 상세 사항은 발제 때 나올 것, 이건 리더/부리더 세션.

기획? 간단한 기획을 준비하기

- 금요일 팀배정 첫 회의 해야하니까. 아무것도 없이 하면 회의 안되니까 기획 초안

- 간단한 기획만! 꼭 받아들여지지 않을 수 있다.

- 단순 모임, 뻔한 커뮤니티 만들지 말 것 (기술 없고 테마 없는 모임 서비스 지양)

- 결제 서비스 하지 말 것 (사업자 등록)

- 기술성 >>> 사업성

기능이 많아 보이거나

기술적으로 1개가 deep하거나

추천 : 기능 여러가지보다 1~2개를 깊게 파는 쪽을 추천

예) WebRTC, socket 등

리더/부리더의 역할

1. 서비스에 어떤 기능이 있으면 고객에게 도움될지 고민

2. 테크니컬 서포트 – 팀원을 도와주어야 한다

A. 제일 중요한 기능은 무조건 리더/부리더가 하라.

가장 중요한 기능은 리더 본인이 하라. API 명세 같은 거 잘 쓰고.

3. 분위기메이커

A. 나이스하게 이야기하자

B. 힘든 상황 자주 맞이하게 될 것, 이 때 함께 힘내면서 하려면.

C. 그라운드 룰 등을 정해두고 하면 좋다.

i. 개인적으로 조심했으면 좋겠는 것들 등을 미리 알고~

D. 카리스마 있는 리더십 X. 분위기에 좋지 않고. 설득과 파이팅 위주로.

i. 항상 좋은 태도로. 나이스하게.

어떻게 일할 것인가? 협업 꿀팁

- 중간 발표회 MVP 발표회

- 6주를 3주/3주로 나눔

- 첫 3주는 Minimum Viable Product 최소 기능

- 뒤 3주는 잘 붙이고 꾸미고 연결하고.

- 우리 토요일까지 하자~ 무조건 못 하는 사람 한 명씩 생긴다.

화요일 한 번, 목요일 한 번 봅시다~ 식으로 하라. “나 혼자 잘하고 있는데 왜 자꾸 쪼지?” 라고 느끼는 사람들 있다.

반드시 “타임라인”을 세팅하고 일하라는 것.

디자이너

- 디자이너와의 소통 중요.

- 중간 합류, 처음에 더 살갑게 대할 것. 함께 만나는 시간을 반드시 정하고.

- 게더에도 합류하실 것임.

- 디자이너와의 소통은 프론트리더가 제1책임. 산발적으로 소통 X

- 디자이너에게 영역을 넘겨주지 말 것, 그리고 디자이너의 영역도 존중할 것

(상호 영역을 존중하기)

Ex) 디자이너 “저 html css 좀 할 줄 아는데” 그래도 그건 FE 개발자 영역.

- 우리는 모든 시간을 항해에 쓰고 있으나, 디자이너는 시간적 한계가 있음을 인지

: 주 20~30시간 정도의 시간 한도.

마케팅

- 실전 발제 때 상세사항 나올 것.

- 마케팅 비용에 사용(광고 등), 쿠폰 지급, 서버 비용을 남겨둔다거나.

- 분위기를 위해 조금 할애해서 치맥 써도 됨

배포는 4주차쯤에는 하는 게 좋다.

SA 피드백 등은 할 것이다.

클론코딩 수요일

알파플라이 — Wed, 22 Jun 2022 19:37:23 +0900

1. 메인페이지

2. 숙소상세페이지

- 일부 정보만 표시되고 있습니다. 전체 정보 표시작업이 아래 여타 작업들보다 우선일 듯 합니다.

- 숙소 삭제, 수정 기능 연결 필요합니다.

- 리뷰 삭제, 수정 기능 연결 필요합니다.

- 숙소정보등록 / 리뷰 작성 / 예약시 alert 띄우고 메인화면 등으로 redirect

: 숙소 등록시 redirect는 잘 되고, alert은 선택사항이라 꼭 필요하진 않을 것 같습니다!

- 리뷰 작성시 새로고침 해야만 반영되는 부분은 수정이 필요합니다.

- 리뷰 표시할 때 리뷰 사이 간격을 띄워야 보기 좋을 것 같습니다.

- 리뷰 작성시간이 datestring 형태 그대로 노출되는데

이 부분을 .toLocaleString 등을 통해 사람이 보기 편한 표기로 바꿔주면 좋겠습니다.

- (하얀님) 리뷰 표시가 시간순으로 잘 되어서 출력되는지 확인

- (재영) 예약하기 API 확인하기

- (재영) 예약취소 API 확인하기

: accommodations의 Vacancy 객체가 잘 적용되는지,

캘린더에 예약가능 날짜/불가능 날짜가 구분되어 잘 표시되는지

* 예약하기 기능은 수정 API 없습니다. 원하시면 만들 수는 있는데 수정이 생기면

예약날짜 왔다갔다 관리가 차질이 생길지도 몰라서요.

------ 이하는 해결되었거나 많이 중요하지 않은 사항들입니다 -----

- 리뷰 달기 기능에서 사진 잘 올라가는지 (OK)

- 숙소정보 등록 / 리뷰 등록시 사진 업로드까지 잘 되는지 (OK)

- 로그인 하지 않으면 상세화면으로 들어가지 못하고 흰 화면이 나오는 점 수정 필요합니다.

그리고 이렇게 빈 화면이 나오면 뒤로가기를 눌러도 메인으로 돌아가지 못하는 것 같습니다. (OK)

1. 숙소정보 삭제나 리뷰 삭제시 S3의 사진도 삭제되게 구현할 수 있는지?

2. 숙소정보등록 / 리뷰 작성시, 마지막에 "작성하기" 버튼을 눌렀을 때만 사진 업로드 API를 실행하게 할 수 있는지?

: 이렇게 하지 않으면, 사용하지 않는 사진들이 S3에 쌓여버리게 되는 문제. 아래와 같은 로직이 혹시 가능할지?

: 1) 사진 등록 버튼을 누르면 단순히 파일 정보를 읽어서 미리보기 보여주는 것까지만 가고,

2) "작성" 버튼을 눌렀을 때 사진정보 API를 호출해서 실제로 사진을 S3에 업로드한 뒤

3) 2)에서 주어진 사진 이미지 url 배열을 photos 변수에 넣어서 숙소등록 또는 리뷰작성 API를 호출한다

3. 좋아요 기능의 경우 API는 원하시면 금방 만들어드릴 수 있습니다.

기존에 로직을 만들어 둔 코드가 있어서 적용하고 테스트만 해보면 될 것 같아요.

협업 규칙들 code of conduct

알파플라이 — Wed, 22 Jun 2022 11:27:44 +0900

시간 준수, 서로 간 배려 등의 기본적인 사항은 믿고 갑니다.

캠 이슈

항해99를 진행하면서, 캠을 늘 켜놓는 것에 대해서 피로감을 느끼는 크루원들이 많이 계신 것 같고 저 또한 그렇습니다. 제 생각으로는 개발 진행중에는 자율적으로 on/off 하되, 누군가와 대화를 할 때는 짧게 한 두 마디 하더라도 반드시 캠을 켰으면 좋겠습니다. 물론 다 같이 이야기해보고 결정할 문제이구요. 이번에는 1주간이 아닌 6주간 프로젝트이기 때문에 서로 친밀한 분위기에서 진행하는 것이 중요하다고 생각해요. 어떤 말을 하더라도 최소한 캠을 켜고 얼굴을 보면서 소통하는 것이 혹시 모를 불필요한 오해, 감정적인 소모를 막기 위해 좋지 않을까 싶습니다. 여튼 이 주제는 다같이 토론해서 결정해봐요.

실시간 상황 공유

매일 작업 시작 전, 작업 종료 전에 최소 2회 서로 상황을 공유합니다.

1) 어떤 부분을 해결하는 중인지

2) 어느 정도 진척되었는지

3) 문제에 직면해있다면 어떤 문제인지

4) API 문서, 변수/함수 이름, request나 response의 형태 등 상호간 공유해야 하는 정보에 수정사항이 생기지 않았는지

최대한 지연 없이 소통하며 진행합니다.

서버 빨리 열고 실제 환경에서 기능 테스트하기.

- 위 실시간 상황 공유와 같은 맥락입니다. 개발 중 어떤 기능 또는 페이지를 만들었을 때나 특정 문제를 해결했을 때 자신의 로컬 저장소에만 그 결과를 갖고 있다면, 협업의 관점에서는 그 작업은 아예 진행되지 않은 것과 같습니다. 뭔가를 만들었을 때, 뭔가를 해결했을 때 바로바로 업데이트 해서 모두가 확인할 수 있게 합시다. 특히 협업 개발은 절차적인 프로세스를 따르게 되는 경우가 많습니다. 내 작업을 끝내고 업데이트해줘야 자신의 기능을 더 개발하거나 테스트할 수 있게 되는 다른 팀원이 있을 것입니다.

- BE는 최대한 빨리 backend 서버를 엽니다 - FE 에서도 API 테스트가 가능하도록. 모든 API 작성이 완료된 후에 로컬에서만 테스트 하다가 서버를 짠! 하고 연다는 생각 X. 아주 조금의 API라도 기능할 때 서버를 열고, FE 팀원 분들이 프로젝트 진행 중 실시간으로 테스트, 수정할 수 있는 - mock API 등이 아니라 실제 우리 팀의 API를 연결해서 - 환경을 조성합니다.

- FE도 마찬가지로, BE 자체적으로 API 테스트(Postman, Thunder Client 등) 할 때와 브라우저 환경에서 테스트할 때 환경에 따라 코드 동작의 차이가 생길 수 있으므로 FE 배포를 일찍 해주시면 훨씬 수월한 진행이 가능합니다. 모든 페이지가 완성되고 CSS 까지 다 예쁘게 먹인 다임에 짠! 오픈하려고 하지 말아주세요 ㅠ

GitHub

- FE / BE 별개의 repository 사용.

- 각 repository 내에서 branch 이름은 일정 형식에 맞게 정합니다. 분담한 기능 또는 페이지가 담당하는 자원(resource)를 지칭하는 이름으로 짓는 방법이 좋을 것 같은데 다른 아이디어도 공유하고 협의해서 결정하면 좋겠습니다.

예) feature_users / feature_articles / feature_comments

- merge 할 때 반드시 "어떤 브랜치를 어떤 브랜치에 merge 하는지" 확인하고 합니다. 기본 세팅이라면 main 이란 브랜치에 각자의 브랜치를 병합하게 될텐데

"Merge (from) feature_users into main" 입니다. 반대로 하는 경우를 주의해주세요.

- 아래(더보기)는 제가 git 사용하는 방식입니다. 각자 git 사용법은 다르니, 이대로 하지 않으셔도 좋습니다만 만약 git이 헷갈리시거나 자꾸 문제가 발생하신다면, 아래처럼만 하셔도 크게 문제가 생기지 않습니다.

1. 로컬 프로젝트 폴더 설정 및 원격 저장소 연동

1) 프로젝트 폴더에서 콘솔창 실행

2) 로컬 저장소로 사용할 폴더를 설정

git init

3) 원격 저장소의 주소를 설정

git remote add origin "git주소"

git remote add origin https://github.com/alpha-fly/shop_advice_backend.git

4) (원격 저장소에 이미 초기 코드가 있다면)

git pull origin main / 또는 git clone "git주소"

git pull origin main
(or)
git clone https://github.com/alpha-fly/shop_advice_backend.git

(clone을 할 경우 3, 4는 순서가 바뀌어도 됩니다)

2. 자신의 branch 생성하고 동시에 그 브랜치로 이동

git checkout -b "브랜치이름"

git checkout -b feature_users

(로컬 저장소에 자신의 branch를 생성하며, 앞으로 업로드시 이 브랜치를 계속 사용하게 되고, 원격 저장소에도 이 이름으로 된 branch에 계속 push 할 것입니다)

3. 작업물 업로드 하기 - "내 로컬 브랜치에서, 내 원격 브랜치로 업로드"

요약하자면 이렇습니다

1-1) git add . (모든 파일을 commit 하려고 할 때)

git add .

1-2) git add "특정 파일 경로와 파일 이름" (특정 파일만 commit 하려고 할 때)

* 보통은 1-1처럼 모든 파일을 commit 하면 git이 알아서 변경사항 있는 파일들만 commit하게 해주지만, 같은 파일을 동시에 2명 이상이 작업하는 경우가 있다던지 특이사항이 있을 땐 지금 올리려고 하는 특정 파일만 골라서 commit 하는 것이 안전할 수 있습니다.

* 아래 예시와 같이 여러 개의 파일을 지정할 수도 있습니다. 경로는 현재 폴더 기준입니다.

git add app.js routes/users.js models/user.js

2) git commit -m "커밋 메시지"

* 커밋 메시지는 반드시 작성해주세요. 형식화된 커밋 메시지를 사용하면 더욱 좋겠습니다...만 프로젝트가 진행되면서 이 부분까지 신경쓰기 어려워진다면, 형식은 뒤로 하더라도 어떤 수정/추가 사항을 commit 하는지 반드시 작성 부탁드립니다.

git commit -m "ADD: 회원 탈퇴 기능 추가"
git commit -m "FIX : 예약기능 오류 수정 - 변수명 변경 및 data type 설정"

3) git push origin "나의 브랜치 이름"

* 일단 나의 branch에 push한 뒤에, 검토를 거쳐 github 웹페이지에서 merge 합니다.

* main 브랜치에 push 바로 하는 것 노노...

git push origin feature_users

4. 병합하기

merge는 커맨드 입력보다 직접 github 웹페이지에 접속해서 하는 것이 쉽습니다.

아래와 같은 절차로 해주시면 됩니다.

단, Automatically Merge가 안되고 conflict가 발생했다면 일단 중지, 팀원을 호출하시고 같이 해결해주세요.

push 한 사항이 있다면 위와 같은 메시지, 버튼이 떠 있을 것입니다.

push 했는데 메시지가 안 떠있다면, 자기 브랜치를 선택해 들어가보면 위 이미지와 같이 작게 메시지가 있을 겁니다.

!! 이 화면에서 상단에, 어디서 어디로 merge 하겠다는 건지 꼭 확인하고 Create 눌러주세요 !!

merge

5. 내 로컬 브랜치를 메인 브랜치와 동기화 하기 (git pull origin main)

- 사실 현업에서 git을 사용하는 방식은 현재 저희와 많이 다른 것 같습니다. branch를 일시적으로만 사용하고, 목적한 기능(feature)이 구현되면 병합 후에 해당 브랜치를 삭제하는 식으로...

- 여튼 우리는 branch를 잘 삭제하지 않고 유지하면서 개발하기 때문에 중간중간 github 원격 저장소의 main브랜치와 내 로컬 저장소의 코드를 동기화 해주는 것이 필요합니다. 본래는 자신의 결과물을 push 하기 전에 먼저 main 브랜치를 pull하는 것이 바람직합니다만, 이러다가 (드문 경우이지만) 누군가 내 코드 부분을 조금 건드렸다던지 해서 자신이 작업한 결과가 작업 전으로 돌아가버리면 귀찮아지기 때문에, 적어도 자기 결과물을 업로드하고 병합한 이후에는 pull 한번씩 꼭 땡겨주세요.

Troubleshooting : JavaScript의 Type // 브라우저, Thunder Client, Postman 간의 코드 해석 차이 문제

알파플라이 — Wed, 22 Jun 2022 09:31:29 +0900

Thunder Client와 Postman에서 아무런 문제 없이 작동하던 API 가

프론트엔드 페이지 연결 후 브라우저에선 제대로 동작하지 않는 문제가 발생했다.

원인은 Data type.

Thunder Client, Postman 실행시에는

Date type끼리의 덧셈뺄셈 연산, Date type과 Number type의 연산이 모두 무리없이 실행되었는데,

브라우저 환경에서 실행한 결과 위의 연산들이 제대로 수행되지 않고 NaN을 반환하였다.

그래서 아래와 같이, 연산 전에 각 변수의 type을 알맞게 설정하도록 코드를 수정했더니 정상적으로 작동하고 있다.

// 수정 전: 서로 다른 Data type 끼리 연산을 시켰음. Thunder Client, Postman 에서는 작동하나
// 정작 중요한 브라우저 환경에서는 연산들이 제대로 수행되지 않음. (NaN 반환)

const openDays = (closeAt - openAt) / 86400000 + 1;
let Vacancy = {};

for (let i = 1; i <= openDays; i++) {
  let humanDate = new Date(openAt + 86400000 * (i - 1));
  Vacancy[humanDate] = true;
}

// 수정 후 : 연산 전에 각 변수의 Data type을 맞추도록 수정함. 브라우저에서도 정상 작동.

const openAtDate = new Date(openAt)
const closeAtDate = new Date(closeAt)
const openDays = (closeAtDate - openAtDate) / 86400000 + 1;  
let Vacancy = {}    

for (let i = 0; i < openDays; i++) {
  let plusMilliseconds = 86400000 * i    
  let humanDate = new Date(Date.parse(openAtDate) + plusMilliseconds);        
  Vacancy[humanDate] = true;    
}

서버 터미널에서 콘솔 찍어보자고 하신 형근님,

아무래도 타입 문제일 것 같다고 하신 승완님 감사합니다.

Refresh Token 연습중, 개선할 점 & 의문점들

알파플라이 — Tue, 21 Jun 2022 10:36:34 +0900

1. 로그인하면 Access Token, Refresh Token을 발급한다 (response로 Frontend에 보내준다)

* Access Token의 유효기간은 짧다. 이렇게 하지 않으면 Access/Refresh의 의미가 전혀 없다.

2. Frontend는 Access Token, Refresh Token 모두 Local Storage에 저장하고,

=> cookie에 담도록 변경하는 것이 권장된다. OK.

평상시의 인증에는 (auth-middleware 인증이 필요한 API 호출시에는) Access Token만을 사용한다.

* Access Token을 사용한다 = request header에 담아서 보낸다.

3. Access Token이 만료되었을 경우, Refresh API를 호출하여야 한다.

FE 요구사항 정리

1. 인증 필요한 API 요청시엔, request header에 Access Token을 담아서 요청

2. Access Token 인증이 실패할 경우, Body에 Refresh Token을 담아서 Refresh API 요청

=> 새로운 Access Token 발급되므로 1. 에서 요청했던 API를 재요청.

3. Refresh Token 인증도 실패할 경우 로그인 페이지나 메인 페이지로 Redirect

=> 이 부분을 백엔드가 자동화할 수 없는지?

FE에서 Access Token 만료여부를 검사하고 Refresh 호출하는 과정을 서버가 해결해줄 수 있는지?

=> 할 수 있으나 하면 안됨.그렇게 하면 Refresh Token 사용의 의미가 하나도 없어짐.

Frontend에서 Refresh API를 호출시 ~~request body에 Refresh Token을 담아 보내주어야 한다.~~ Cookie로 해결.

Refresh API 요청을 받으면, Refresh Token을 verify 하고 Access Token을 새로 발급한다.

* 사용자 입장 : Refresh Token은 Local Storage 혹은 cookie에 저장되어 있을 것이다.

* 서버 입장 : Refresh Token은 user DB에 보관해뒀고, 사용자가 보내는 Refresh Token과 비교할 것이다.

서버가 이 부분을 자동화 하려면 (하지 말 것)

1) 사용자의 Local storage 혹은 cookie에 있는 refresh token에 접근이 직접 - FE 의 요청 없이 - 가능해야 한다.

=> 방법은 있을 것 같지만 이렇게 해두는 것은 옳은가? 옳지 않음.

2) Access Token 인증이 실패할 때 Refresh API 에 해당하는 내용을 실행하게 하면 된다.

4. Refresh Token도 만료된 상황을 테스트해볼 것.

: 인증 실패임. 새로 로그인해야 함. (OK. 이게 맞음)

추가 의문점들

1) Refresh Token을 사용자 DB에 저장해두는 것이 좋은가?

- ~~지금은 DB에는 토큰을 관리하지 않고 있음.~~ 넣었음.

지금으로선 R.Token DB에 안 넣어두면 Refresh할 때 엉터리 Access Token 생성하게 됨.

Refresh 할 때, Access Token 새로 생성하면서 사용자 식별이 필요, 이때 refresh token이 key가 되어주어야 한다.

(기존의 Access Token은 만료된 상태이므로)

=> 이거 다르게 구현할 방법은 없는가?

6/20 기술매니저님 멘토링 이후

알파플라이 — Tue, 21 Jun 2022 09:02:26 +0900

1. DB

- mongoDB : MQL (mongo query language) * populate

- mongoDB를 쓴다고 성능에 큰 차이가 나진 않을 것임 (프로젝트 규모상)

- 그러나 시장의 흐름상 SQL이 절대적인 비중인 것이 사실, 데이터 "무결성"이 너무나 큰 장점이다.

- MySQL, PostgresQL 등 무엇을 쓰게 되더라도

1) 각 DB의 장단점을 이해하고

2) query를 최적화할 수 있으며

3) 해당 DB의 원리를 이해 (ex. 인덱스에 어떻게 접근하는가) 하는 것에서 차이가 발생할 것이다.

그리고 DB를 한 종류만 쓰게 되는 개발자는 없음.

2. CICD

- GitHub Action, Jenkins 등

- fit에 맞는 툴을 선택해서 사용할 것.

- 배포자동화시, 테스트를 통과해야 코드 통합이 이루어지고 배포가 되게 한다던가 하는 설정을 할 수 있다. 이런 시스템(?)을 구축해보는 것 자체로도 설득력 있는 경험이 될 수 있음.

3. 프로젝트에 어떤 기술을 적용할지 선택하기 힘들다면?

- 높은 연봉의 개발자에게 요구되는 스택을 살펴보라.

4. 코드를 좀 더 일목요연하게, 함수로 묶어가면서 작성하고 싶은데 그 범위가 어렵다면?

- Single responsibility, SOLID 원칙에 대해 알아볼 것.