22.11.26. Week3 멘토링

멘토링

검색 페이지

페이징

클라이언트에서 한번에 리스트를 받아오는 것도 좋은데
나중에 용량이 너무 많으면 통신이 느려질 수 있다.
그리고 서버에 limit이 정해져있을 수도 있다.

그래서 페이지네이션 스크롤 페이징, 인피니티 스크롤과 같이 쓰이는 페이징을 보고 적용해보자

검색

한글이 생각보다 검색 시, 문제가 많은데 event에 isComposing 이런 것도 알아보고
글이 완성 될 때 검색을 한다던지 searchValue를 계속 기록해서 변화가 있으면 검색을 실행시킨다던지,
setText를 디바운싱걸어서 완전히 끝날 때 setText를 하던지.

검색어를 잘 관리해서 완성해서 호출을 하던가
호출 자체를 디바운싱을 한다던가, 이 두가지 측면 비교해서 좋을걸 써보자.
-> 검색어 디바운싱 vs 호출 디바운싱

---

CORS처리

• NGINX vs 코드 어디서 CORS관리를 해야할까? -> 큰 문제 없으면 코드 상에서 관리하면 좋음

프론트, 백엔드 같이 서버에 올리는 방법

• 키워드 nestJS serve static
• react dev tool이 있는데, 빌드하면 생성되는 dist를 서버에 올리고 라우팅 처리를 적절하게 하면 된다.
• 이걸 적용하면 운영에서는 같은 서버에서 올려지는거기 때문에 CORS에러가 나지 않을 것이다.
• 물론 MSA처럼 분리하면 고려해야겠지만, 하나에 올리면 대부분의 CORS가 발생하지 않을 것이다.

---

메인페이지 BE

메인페이지 진입시 API를 두개 정도 받아오는데
요청이 각각 가게 되는데, 한 페이지에서 날리는 api는 하나로 해서 Y자로 가져오는게 더 좋을 것 같다라는 판단이 안든다.

답변

rest API

하나의 api로 하나의 데이터를 가져올 때의 장점 -> 명확함

두개를 같이 보낼 때 -> GraphQL의 느낌

API통신에서 가장 비용이 많이 드는건 connect disconnect 비용이 제일 크고 send는 작다.
옛날에는 그렇기 때문에 한방쿼리를 많이 했다. 한번에 많이 다 보내버리는..
이렇게 되면 유지보수가 굉장히 힘들다.

요새는 GraphQL이 중간에서 처리
단점은 명확하지가 않음.
api명세 뿐만 아니라 graphQL 명세도 입력해야한다.

이 아이디어가 왜 나왔냐면
페이스북에서 모바일을 사용하면 퍼팅을 하기위해 api를 엄청 많이 불러와야 되는데,
한번에 받는게 무조건 싸다. 그래서 graphQL로 한번에 한다.

장점 : 하나의 endpoint, 자유도가 높음.
단점 : 파일 업로드 불가, 그리고 너무 방대해서 명확함이 없다.

nest가 GraphQL을 잘쓰게 만들어놨다.

• 글로벌 사업을 준비하면서 나온 문제점 : server에서 server까지의 물리적 거리에 속도가 크게 영향을 받는다.
  해외에서 api요청을 10개를 하면 10번이나 느린 api를 전송하게 되는데, graphQL을 적용하면 한번만 보내면된다.

• 글로벌 서비스, 모바일 서비스 환경에서는 쓸 확률이 높을 것 같음.

---

서버 stress test는 어떻게 진행하는지

-> ngrinder (자바?)
스트레스 테스트는 예방의 차원이다.

---

현재 서비스가 CRUD가 주인데, 이게 끝나면 백엔드가 붕 뜰거 같다.

그래서 레디스나 도커 등 도입을 고민 중인데 필요할까? 고민이됨.

• 잔디 칠하기 같은 백엔드처리, 프론트 처리 각각 방법이 다른데 이런 방식에 대한 고민.
  프론트는 화면 동작에 집중하는 것이 좋을 것 같고 백엔드는 로직에 집중하면 좋을 것 같다.
• 백엔드에서 로직을 만들어줄 수 있는 것을 고민하는 좋을듯.
  같은 상황 속에서라도 로직이 복잡해질 수도 있는데 더 잘하는 방법에 대한 고민.
• 시간이 남으면 stress test 보다는 redis가 좋아보임
  가정을 해서(쿼리에 딜레이를 5초씩 걸어서 해본다던지) 진행을 해봐도 좋을듯.

폰트 추천 사이트

• 눈누 -> 상업적 사용 가능 폰트 모음

추천

• 프리텐다드