-
Notifications
You must be signed in to change notification settings - Fork 2
멘토링 4주차
도메인에 종속적인 response vs 공통적으로 쓰이는 response
현재는 src/common/response 폴더에서 관리되고 있습니다.
현업에서는 일반적으로 사용되는 response는 constants, 그 외에 부분들은 각 도메인에서 관리해준다.
추가로, response는 따로 템플릿을 만들어주지 않고 error만 커스텀 에러를 생성해준다.
// 특정 서비스 파일
try{
if (...) {
throw new roomError();
}
} catch(error){
if (error instanceof roomError){
return {...에러 response}
}
}REST API 서버를 구축할 때 도메인을 따로 분리하여 사용하는 방법과, 요청 URL를 달리하여 proxy하는 방법 둘 중 어느것이 더 일반적인 방법인지 궁금합니다.
두 방법 다 많이 쓰인다. 다만 서브 도메인 방법은 서버가 아예 나눠져있는 경우(BE, FE)에 거의 쓰인다. 다만 현재 서비스 환경에서는 하나의 서버에서 모든 처리를 하기 때문에 서브 도메인을 사용하는 것은 적절하지 않아 보인다.
구조 분해 할당을 사용하는 것에 대해 팀원간의 선호도 차이가 있었습니다. (창명: 선호, 윤희: 보통)
멘토님은 구조분해할당 좋아하시나요?
합의만 되면 둘 다 상관없다.
나는 구조분해할당 좋아한다.
추가로, 개인적으로는 컨트롤러에서 받은 DTO를 서비스에 바로 넘겨주곤 한다.
서비스 안에서는 구조분해할당을 추천한다.
외부 API에서 받아온 데이터를 필요한 부분만 사용하도록(마치 컨트롤에서 @Body @Query에서 DTO로 받는 것처럼) 가공하고 싶습니다.
이와 관련해서 조언을 듣고 싶습니다.
@Transform, @Type 데코레이터, plainToInstance 함수를 이용하면 이를 수행할 수 있다.
소켓으로만 데이터를 주고받으면 전송 순서를 보장받을수가 없을 것 같아 걱정입니다.
소켓으로 서비스를 짰으면, 웬만하면 일관성 있게 소켓으로 구현하는게 좋다.
하지만 로그인이나, sessionID 주는 건 REST API 로 작성하는게 일반적이다.
세션 ID 없으니 서버한테 세션 ID 줘. 하는건 REST API로 짜야하고, 그 이후 로직을 소켓으로 짜야 한다.
소켓을 사용하여 데이터의 전송 순서를 보장 받지 못하는 경우는, 쉽게 생각해서 인증이 불가능한 요청에 대한 처리는 모두 튕겨내면 된다.
이미지로 마커를 띄우는데, 마커가 약 40~50개가 넘어가는 순간부터 렌더링 성능이 급격하게 안 좋아집니다.
이에 네이버 지도에서 가이드하고 있는 것처럼 현재 화면에 보여지지 않는 마커는 숨기고, 화면에 보이는 마커만 띄우도록 최적화 작업을 진행했는데도 50개 이상 마커를 띄우면 지도 화면이 굉장히 느리게 동작합니다.
이런 경우 어떻게 최적화 할 수 있을지 궁금합니다.
현재 화면 구성을 보면 겹쳐있는 마커가 많은데 이런 부분을 클러스터화 해주어도 될 것 같다.
하지만 직접 구현하면 로직이 많이 복잡할 것이다.
또, react-query나 useMemo 로도 캐싱이 가능하다. useTransaction 찾아보아라.
현재 API 설계상 하나의 모임에 종속되는 음식점의 수는 400개를 넘기지 않습니다.
때문에 지금까지는 처음 지도가 렌더링될 때 해당 음식점 데이터들을 전부 내려줬었지만, 사용자가 많아질 경우를 생각해서 최적화를 고민하다보니 현재 지도에 나타나는 음식점들만 선택적으로 그 때 그 때 서버에서 가져와야 할지, 아니면 음식점 정보는 전부 클라이언트에서 가지고 있다가 렌더링만 선택적으로 해주어야 할지 고민이 됩니다.
현재 후자 방법으로 구현하였습니다.
사실 두 방법 모두 해보면 좋겠지만 개발 시간이 촉박하여 멘토님은 이에 대해 어떻게 생각하고 계시는지 먼저 이야기를 듣고 싶습니다.
API 응답 속도는 0.01 초가 best 이다.
현재 응답에 1초가 걸린다면 redis 를 사용해라. 사용자가 많아지면 10초가 될 수 있다.
데이터가 메가 단위가 아니라면 클라이언트에서 전부 들고 있어도 되기는 하나, 캐싱을 하는것이 좋다.
단, 현재 데이터 규모에서는 차이가 많이 나지는 않을 것 같다.
매번 데이터를 불러오는 경우 오른쪽으로 스크롤 했다가 다시 왼쪽으로 스크롤하여 돌아갔을 때 다시 로딩이 발생하는데, 이러면 UX 가 떨어진다.
개발자도구로 가능하다.
네트워크 탭에서 얼마만큼의 용량를 몇초만에 가져왔는지도 볼 수 있다.
프론트엔드, 백엔드 레포지토리가 대부분 나눠져 있어서 DTO 를 공유하기가 쉽지 않지만 사용할 수 있는 방법은 있다.
- git의 submodule를 사용하는 방법
하지만 생각보다 별로다.
- 모노레포 & lerna
client, server, shared 폴더구조를 사용
서버에서 DTO 를 고치면 클라이언트에서 문제가 발생해서 즉각적인 반영이 가능하다.
소규모의 프로젝트에서 주로 사용한다. (대규모는 타입 공유를 하지 않고 각자 사용하는 편이다.)
lerna 를 사용하지 않고 그냥 shared 폴더안에 타입을 넣어놓고 써도 문제는 없다.
-
||은 위험할 수 있다.??문법을 사용하자. (0,''등 의도한 값들도 false 로 판단하여 걸러질 수 있기 때문에) - 의견공유가 싫어서 yes맨이 되지 말자
- 의견을 가지고~~ 싸우자~~~ 뒤끝없이~~^^