FE
2주차 데일리 스크럼
2주차 회고
2주차 회고
Search
2주차 트러블 슈팅
Git Branch Error
boring-avatars error
로그인 기능 구현 중 msw의 버전 변경으로 인한 오류
2주차 멘토링
멘토링 전 질문(Q&A)
데모데이를 보니 많은 팀들이 웹소켓을 사용해 채팅 기능을 구현했더라고요. 그런데 저희 프로젝트는 웹소켓을 사용하지 않고, CRUD 기능에 더 중점을 두고 있어서 상대적으로 비교될 수 있을 것 같아 걱정이 됩니다.
멘토님 답변 및 피드백
•
이전 기수들도 비슷한 고민을 하셨어요. 그때는 그래프나 지도 기능을 추가하거나, 어떤 팀은 오디오 API를 사용해 보이스 녹음 기능을 구현했습니다. 이러한 방식으로 프론트엔드에서 추가적으로 구현할 수 있는 기능을 고민해보는 것이 좋을 것 같습니다.
•
현재 프로젝트 범위 내에서 구현할 수 있는 것들을 기획해보면 좋을 것 같아요. 예를 들어, 차트나 지도를 연동하거나, 드래그 앤 드롭과 같은 다양한 인터랙션을 추가하면 프론트엔드에서 할 수 있는 것들이 많아집니다. 이를 통해 프로젝트의 세부 디테일을 살릴 수 있습니다.
•
현재 게시글 작성 단계에서는 지도 마커를 사용해 새로운 기능을 만들 수 있을 것 같습니다. 또는 전통주의 분포도나 날씨에 어울리는 술을 추천하는 그래프 등을 구현하는 것도 고려해볼 수 있어요.
•
Three.js로 모델링을 구현하는 것도 한 가지 방법입니다. 이전 기수에서는 게임 플랫폼 프로젝트에서 Three.js로 무기를 모델링해 시각화하는 기능을 구현한 사례도 있었습니다. 다만, 전통주 같은 주제에서는 모델링 파일을 구하는 데에 어려움이 있을 수 있어서 이 부분 말고 다른 방법을 추천드립니다.
또한 알림 기능은 SSE(Server-Sent Events)로 구현하면 효율적일 것 같습니다.
•
자동완성 기능이 있는 검색의 경우, API를 계속 호출하면 서버에 부하가 발생할 수 있기 때문에 캐싱을 하거나 디바운싱을 통해 호출 빈도를 줄이는 방법을 고려해야 합니다.
•
마지막으로, 네트워크가 끊겨도 좋아요 버튼을 눌렀을 때, 좋아요가 적용된 것처럼 보여지게 만드는 것도 사용자 경험 측면에서 좋을 것 같습니다. 네트워크가 느려도 즉각적인 피드백을 제공하는 것이 중요하기 때문입니다.
•
컬러 팔레트 변경 필요
주포인트 색깔은 강렬한게 좋음(ex. 당근마켓-주황색 / 쿠팡-파란색)
•
Git PR
코드 리뷰 또는 짧은 의견 작성 중요. 나중에 기술 면접관에게 어필 가능
•
중요 변동사항은 slack에 꼭 공유할 것!!
[pre documents]
•
전송 형식
파일 객체 올릴 때 multipart/fomdata로 전송 필요
application/json 형식으로 전송 X
•
CORS 이슈
도메인간에 다른 부분들에 대해서 리소스를 cross 할 수 없는 규칙
백엔드에서는 Access-Control-Allow-Origin 설정으로 해결 가능
프론트 개발 서버에서는 proxy설정으로 우회 가능
실제는 서버에서 설정 필요
•
협업 Flow
git flow 사용중
release, hotfix 브랜치는 당장 필요X
•
깃모지 자동화
.vscode/setting.json 새로 생성
{
gitmoji.outputType: "emoji",
gitmoji.addCustomEmoji" : [
{
"emoji" : "",
"code" : ": :",
"description" : "설명",
},
•
확장 프로그램
@popular 가장 인기 있는 확장 프로그램 리스트
spell checker : 오타 방지, 함수나 변수를 CamalCase로 안썼을 경우 경고 노출
path intellisence
확장프로그램 자동화 => 작업 영역 내 추가 권장 사항 => .vscode 폴더 내 설정파일 생성 => 같이 커밋
•
영어 단어에 맞지 않는 경우(ex. mypage)
빠른수정 => workspace setting => 예외처리
.vscode/setting.json 파일 내 작성됨
코드 스펠 체크 자동화
•
eslint & prettire 자동화
공통 설정 .vscode/setting.json 내 작성
•
디자인 패턴
컴포넌트에 맞는 다양한 패턴 사용을 해보는 것이 본인의 패턴을 만드는 데 큰 도움이 됨
필요에 따라 여러 패턴을 사용함
드라이를 지향하되 한번 더 추상화가 되어야 하는건 아닌지 체크할것
유틸성 함수들은 드라이 하지 않는게 좋기에 파일로 따로 분리
•
package.json
트리 쉐이킹 작동 원리 확인
•
axios
반복되는 값은 개별 instance 생성
application/json 파일을 받을 수 있는 형태로 작성 또는 multipart/formdata 로도 받을 수 있도록 content-type을 유동적으로 변경할 수 있게 작성 가능
interceptor : (request)API 호출 시 필요한 Bearer 토큰을 instance 한곳에서 관리 가능
(response)인증 정보 만료와 같은 오류 페이지에 대한 처리를 instance에서 처리
fecthCall : 공통 fetch call, get/post/delete 메서드를 인자값으로 받아서 사용 가능
•
hooks
다른 프로젝트에서도 활용 가능한 공통 hooks 사용 권장
[플젝 관련 질문]
Q. CRUD에 너무 치우쳐저 있는것 같다
FE에서 할 수 있는 내부 기능을 추가
지도/그래프/audio api(보이스 녹음)/차트/drag&drop
지도 => 마커(병들)로 표시
그래프 => 많이 애용하는 주류에 대한 분포도
차트 => 날씨에 따른 주류 퍼센트
주종 3jx 모델링 구현
또는 에셋으로 술 3d로 구현
알림 => SSE(단방향 소켓 통신) 많이 활용
서버에서 내려주는 값 받아서 or 이벤트를 받아서 이벤트 핸들링
자동완성 => defer 처리 가능
계속 API를 호출하면 부하가 걸리기 때문에
디바운싱 처리를 통해 덜 호출하도록 처리 가능
하트 => 인스타그램처럼 네트워크가 비활성화 상태일때도 처리가 될 수 있도록
BE
2주차 데일리 스크럼
2주차 회고
2주차 회고
Search
2주차 트러블 슈팅
macOS에서 MySQL과 MariaDB 충돌
PR 머지 순서로 인한 마스터 브랜치 충돌(conflict)
Postman에서 JWT 토큰을 포함한 API 테스트 실패
CSRF 토큰 관련 403 Forbidden 에러
2주차 멘토링
멘토링 전 질문(Q&A)
•
프로필, 특산주 이미지를 BE 단에서 AWS S3에 저장하는 게 나을지 아니면 프론트에서 저장후 URL만 넘겨받는게 나을지
•
리프레시 토큰이 엑세스 토큰만큼 자주 주고받진 않아서 탈취 위험이 적긴 하지만, 아예 확률이 없는것은 아니라 탈취시 그것을 무력화하는 방법
•
리프레시 토큰으로 엑세스 토큰을 재발급 할 때, 신뢰성을 높이려면 DB에 따로 저장해두는 방식이 나을지
•
비밀번호 재설정 기능 구현할 때, 재설정 링크의 보안 강화
•
액세스 토큰, 리프레시 토큰, 비밀번호 재설정 토큰 각 만료 기간을 설정할 때 적절한 기준
멘토님 답변 및 피드백
•
보안 이슈를 미리 예방하기 전에 구체적인 탈취 위험 및 사례 등을 보고 판단할 것
•
대부분의 보안위험이 있다는 등의 글들은 주니어 개발자 입장에서 작성한 글이므로 글의 맹목적인 신뢰를 가질 필요는 없음
•
금융권 및 결제 시스템이 아닌 이상 보안 정책은 개발자가 정하기 나름(합리적인 근거를 토대로)
•
AWS S3 이미지 저장 처리
◦
주로 접근 권한 관리, 자격 증명 정보, 파일 검증, 추적 및 로깅 등 서버 보안 관리 측면에서 백엔드에서 주로 담당함
◦
성능 부하가 증가 할 수 있는 이슈가 있어 무리가 가지 않을지 검토가 필요하지만, 대규모 서비스가 아니고, 많은 데이터를 다루지 않을 것이기 때문에 무리는 없어 보임
◦
프론트와 백엔드에서 각각의 보안 문제를 크로스체크하여 비교할 필요 있음
•
리프레시 토큰 같은 경우에 DB에 저장할 필요 있음
•
결제 시스템이 아닌 이상 엑세스 토큰을 저장하지 않는 경우도 많음
•
프로젝트의 퀄리티 및 실력 향상에 단기간 올릴 수 있는 것이 채팅(소켓 통신)
◦
프로젝트의 일정, 남은 기능 구현의 상황에 따라 추가적으로 접목시키면 괜찮음
•
트랜잭션 어노테이션 남발 금지 -> 데이터 무결성과, 자동 롤백의 장점이 있지만, lock을 사용해 트랜잭션을 과도하게 사용하면 성능 저하, 시스템 자원을 많이 소모, DB 락이 길게 유지되어 다른 트랜잭션 작업에 지장을 줄 수 있음(데드락)
•
테스트 코드 작성 요망
◦
테스트 케이스를 작성해 다양한 시나리오에 대응할 필요
•
macOS DB 충돌 관련
◦
도커 컨테이너를 통해 운용 및 관리하면 환경과 편리성 면에서 더욱 간편하게 사용할 수 있음