바로 db에서 삭제하는 것이 아니라 일정 유효 기간을 두고 한꺼번에 쌓인 것들 삭제하는 식으로 작성하는 것이 어떤지
=> cron 참조
주기적으로 db 확인해주고 일정 시간이 지나면 지우도록 하는 것도 괜찮을 거 같음.
get, post는 기존에 존재하던 것과 달리 put, delete는 나중에 나옴.
앞의 두 개보다 뒤의 두개가 문제가 많다고 볼 수는 있긴 함.
그러나 get과 post만 써야한다는 건 아니고 put과 delete가 100% 안전하다고 할 수는 없지만 많이 걱정을 할 필요는 없을 것.
불필요한 접속 방지.
여기서 어떤 메서드의 요청을 받을지 정할 수 있음.
cors documentation 참조.
https://evan-moon.github.io/2020/05/21/about-cors/
둘이 큰 차이가 없음.
하지만 관리적인 측면에서는 ref를 이용하는 게 좋음
프론트에 이미 데이터들이 전달되어있다고 하지만 데이터가 얼마나 신선한지를 봐야 함.
텀이 짧다면 프론트에서 하는 게 시간이 적게 걸림.
만약 백엔드에서 검색어를 받고 검색 결과를 프론트에 전달한다면
자동완성 기능같은 경우 onChange 이벤트 일어날 때마다 요청이 발생하는가?
=> 회사마다 다르다.
글자 하나 당 요청을 보낼 수도, 자음, 모음 하나 당 요청을 보낼 수도 있다.
threshold 생각을 해야 함.
input을 받을 때 몇 초간에만 입력을 받고 그것들을 모아서 쿼리 하나를 보내자
=> throttle은 일정 시간마다, debounce는 입력이 끝난 후 요청
아니면 처음 입력 몇 개만 보고 결과들을 다 프론트에 전달한 뒤 프론트에서 알맞은 걸 골라서 처리하는 방법도 있음.
사용자에게 안 보이게 일정 시간 지나면 데이터 다시 신선하게 돌리는 방법도 좋음
이 경우 무한히 돌아가는 코드이기 때문에 페이지를 이동한다던가 하면 죽여줘야 함
이거 회사들 많이 사용.
사용자가 많으면 필요.
참조
https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Expires
git GUI 툴 못 쓸 경우 gitHistory 사용
🩹 오피스아워 후
: 여러가지 궁금했던 부분들을 현직자 분에게 여쭤볼 수 있는 기회가 생겨서 너무 좋았다.
특히 개발 외적으로 보안쪽으로 신경써야할 부분이나, 잘못하면 그냥 지나가는 부분들도 집어서 알려주시는게 너무 좋았다.
코드 리뷰 부분에서 쿼리를 한번만 해도 되는걸 여러번 하거나, 이름의 통일성이 없는 부분 등이 있어 수정사항을 받았고,API path
를RESTful
하게 만드는 법도 배울 수 있어 아주 유용했다!
여러가지 수정사항이 나왔지만 수정사항이 나왔다기보다 더 발전할 수 있는 방법들이 나온 것 같아 기분이 너무 좋았던 코드 리뷰 였다!
다음번엔 코드 리뷰를 완벽하게 통과하는걸 목표로 잡아야겠다!