[Meet up with Mentor] 22.11.24

🙋‍♂️[FE, BE] 쿠키에서 HTTPS 설정이 잘 안된다.

🧑‍🏫 nCloud에서 HTTPS를 하려면 도메인을 사야함 → AWS로 해야 함

😀 도메인 사는거 nCloud에서 우리 비용을 내서 살 수 있지 않나?

🧑‍🏫 따로 사야 함 (공인 IP)

🧑‍🏫 원래는 프론트 호스트와 백엔드 호스트를 맞추는 것을 하는데, 동일한 서버가 아닌 경우가 많음

🧑‍🏫 reverseProxy를 해서 백엔드 특정 api 패스에 접근하면 백엔드에 응답을 받아서 프론트서버로 응답해주는 방식을 많이 씀

하나의 호스트에서 백엔드 프론트 둘 다 바라보는 방식

NGINX로 작업하는 거하고 aws 사용하는 거와 다른 얘기

🧑‍🏫 보통 쿠키가 얽혀있으면 같은 호스트로 맞추긴 한다, 같은 호스트로 맞춰야 할 거 같다.

😀 따로 배포하는 경험을 하고 싶었으나 문제가 복잡하면 같은 곳에 배포를 하는 방식으로 해야겠다.

🧑‍🏫 sameSite를 지원하지 않는 브라우저도 있음

🧑‍🏫 보통 여기서 하는 방식은 백엔드쪽 서버에 프론트 빌드한 거 넣어놓고 루트로 들어온 경우에 프론트 쪽 리소스를 반환하도록 구현하긴 함

😀 프론트 쪽에 서버를 둬서 서버에서 서버로 요청받는 방식은 어떤가요?

🧑‍🏫 SSR을 하지 않기 때문에 프론트 서버 필요 없을거 같다.

🧑‍🏫 6주차쯤 되었을 때, nCloud를 버리고 다른 쪽에 배포하는 방식 생각해보도록

🧑‍🏫 백엔드가 완료되어야 프론트가 잘 동작됨 → 백엔드가 완전히 완성되서 넘어오는 경우는 거의 없었다. → 프론트는 백엔드가 API를 늦게 줄 것을 감안해서 일정을 잡아야 함.

💁‍♀️[FE] 접근성 고려해야할까요?

접근성 프론트 엔지니어에게 중요한가?

케바케다. 법적으로 지정되어있다. 하지 않으면 벌금 있을걸요. 근데 담당하는 분이 따로 있긴 한데 신경 많이 못 쓴다. 특히 이미지 읽어줄 수 없으니 대체 텍스트를 잘 채워줘야한다. 이걸 최선으로 한다. 정말 중요한 페이지는 tabindex로 탭 순서도 정해줄 수 있다~ 이건 근데 개발자 역량으로 하고~

제대로 하려면 테스터가 따로 있다~ 그렇게 신경 쓰진 않는다~

신경 안쓰는 경우도 많은듯~

면접 때 PR하기에 좋은 거 같아요~

사용자가 올리는 이미지~ 이런 건 대체 텍스트 쓰기 힘들다~

💁‍♀️[FE] React router dom v6 Loader

로더, 액션 같은 props가 새로 생겼는데~

라우터를 렌더링하기 전에~ 로더를 쓰면~ 데이터가 오기 전까지~ 해당 라우터로 넘어가지 않으니 spinner를 쓰지 않아도 되네요~

그렇다면 언제 로더를 쓰는 게 적절할까요~

1. 로더 쓰기: 라우터로 건너가기 전에 데이터 불러오기
2. 로더 안 쓰기: 라우터로 건너가서 데이터 불러오기 fetching하는 동안 spinner 띄워주기

일반적으로는 페이지 이동 간에는 indicator 안 쓴다.

보통 SSR은 페이지에 필요한 API 다 호출해서 데이터 다 불러오고 페이지 짠 띄워줘야한다. mount된 후에 API 호출 ㄴㄴ 로더로는 채팅방 목록 다 가져와서 컴포넌트에 넣어놓으면 다 채워진 채로 렌덜이이 되겠죠 그러면 이걸 SSR로 날릴 수 있다

로더 없으면 데이터 못 채워보내니까~ 이게 react router dom의 단점이었는데 v6에는 loader가 도입되었다~

지금은 채팅방으로 넘어가면 API 호출하잖아요? 응답 빨리 받을 수 있다면 데이터 다 받고 렌더링하는 게 좋음~

next.js에서 server side props가 이런 역할을 한다.

action은 무슨 말인지 잘 모르겠음 공식 문서 읽어봤는데 희한하네요~

페이지 접근할 때 (저?) api를 써도 괜찮을거 같다.

💁‍♀️[FE] 주석 달기~

코드로 말하는게 제일 좋다는데~ 그렇다고 해서 주석을 아예 안 쓰는 게 맞는걸까~ 내가 만든 함수를~ 다른 사람이 쓰려면 주석을 써주는게 좋은 거 같은데~

정답은 없지만 SOLID 원칙에 기반한다면 주석 없어도 될 듯요~ 작고~ 명확한 함수 네이밍~ 함수 하나당 작은 로직~

지금 보여주신 코드는~ 주석 엄청 좋은 거 같아요~ webstorm 에디터~ 좋아요~

제가 말씀드린 건 로직에 있는 주석이었는데~ 그런 거 말고 함수 descrption에 써놓은 거는~ 좋은 거 같아요~

전체적으로 봤을 때 프로젝트 난이도가 어려운 거 같아요. 스펙이 어렵네요~ 주기적으로 API 호출하고~ 그다음에 소켓하는 것도~ 나쁘지 않아보이네요~

💁‍♂️[BE] async, await으로 구현해서 전부 기다리는게 비동기의 장점을 살리는지 모르겠다.

🧑‍🏫 repositorty이고 경우에 따라서 판단을 해야하는 부분 기다려야 하는 경우가 있을 거다.

🧑‍🏫 굳이 기다리고 싶지 않으면 service에서 await을 빼면 된다. 근데 어느 곳에서는 저것을 기다려야 되는 경우가 있을테니까 그런 범용성을 생각하면 async, await을 놔두는 것이 좋다고 생각한다.

🧑‍🏫 void를 쓰면 → promise를 반환했는데, promise를 기다리지 않고 지나가겠다.

😀 create를 기다리지 않고해도 괜찮을까요?

🧑‍🏫 저는 댓글을 쓰고 create한 응답이 오면 댓글 목록을 다시 불러옴, create를 기다리지 않으면 create 중인데 응답이 왔을 때 댓글 목록을 새로고침 함, 근데 create가 안끝난 상태라 댓글 목록이 오지 않는 경우가 있을 수 있음

🧑‍🏫 백엔드가 삭제가 되지 않았는데 응답을 줄 수 도 있음 → 프론트에서 보정해서 보여주는 경우도 있음

ex. 댓글을 API 써서 추가했는데, 그 후에 추가된 댓글을 API 통신없이 추가된 것 처럼 보여주는 방식 ⇒ optimistic update

🧑‍🏫 채팅 추가했을 때 redux에서 추가해서 백엔드에 부하를 감소시키긴 한다.

🧑‍🏫 우리의 서비스에서는 기다려야할까 기다리지 않아도 될까? 고민해보면 좋을듯

💁‍♂️[BE] Unit Test를 왜 해야하는지 모르겠다.

😀 복잡한 서비스 아님 → 서비스 로직에서 별로 처리하는 게 없는데, UnitTest를 하는게 옳은가? 대부분이 다 레포지토리를 그대로 가져온다. 과연 unit test가 의미가 있을까를 고민한다.

🧑‍🏫 그러면 저는 BDD 테스트를 해보시는 것을 추천 행동기반 테스트 → UnitTest는 가장 작은 테스트, BDD는 사용자가 실제 서비스를 하면서 API를 쏠 텐데 그걸 테스트하는것.

BDD Test : 순서대로 잘 오는지 (회원가입 → 로그인 → …) API레벨로 테스트 짜는 것 (프론트 없이)

채팅방 하나 만들어보고 써보고를 테스트 코드로 짤 수가 있다.

이 프로젝트에서는 BDD가 더 의미 있는거 같다.

모두가 한다고 해서 정답은 아님, 일반적으로 간단하고 효과가 좋은거지 정답은 아님

TDD의 가장 큰 장점은 간단한 구현과 좋은 테스트 커버리지이다.