html이동에 어려움 window.location.href ="/template/chat-room.html/; url로 이동은 하는데,, template는 정적인 페이지를 만드는 곳,,static으로 옮기는게 /chat-room.html로 수정
업데이트 꾸준히
필요에 의해 바꾸는게 좋아보임. 연습겸으로 사용하는 건 x 이유가 있어야함(QuearyDSL을 사용한 이유?) JPQL, QueryDSL의 장단점을 비교 분석하고, 우리가 사용하면 좋을 걸 정하자 QueryDSL 동적쿼리 : if문 JPQL로는 동적쿼리가 처리는 되지만 QueryDSL처럼(메서드사용)은 힘들고 string으로 코드를 짜야하고 에러가 너무 많이 발생함
하면서 바꾸면됨, 팀 구성원의 코드스타일이 같아야함(한명이라도 람다식을 이해하지 못했으면 사용x)
안놔눠도 상관 x 나누지 않은 이유(정당성)만 알면됨
Docker 사용은 무조건 추천 Docker는 실무에서 200%사용함. 안쓰는 곳이 없음 이번에 올라온 Docker강의 올라온거 있으니까 하루면 충분.그것만 알아도 사용할 수 있음 용어적으로 어려운것이 있을 수는 있어도 Docker개념 자체가 어려운 건 아님. 무조건 하셈
남아있는 기능들을 어떻게 할 지 고민 유동적으로 ㄱㄱ 로그아웃은 하고 소셜로그인, 이메일 인증은 굳이? 가져다쓰는거라. 둘 중 하나쓰라고 하면 소셜로그인으로. 이메일 인증은 도움 안됨 잘 안쓰는 추세 로그아웃, RefreshToken > 소셜로그인(Oath) RefreshToken을 빡세게 하는걸 추천
Test코드는 무조건 작성해야함
근데 도메인이 너무 많아서 어떻게 하죠?
통합테스트는 필요 없음(=Postman) intellij http로 대체 가능. 소개하기 좋음. 우리 이런거도 썼음 service layer 단위 테스트가 중요 controller, repository는 안돼도 되는데 service는 무조건. 목 객체 시간이 부족해서 전체가 힘들다면 중간중간 꼭 검증 해야하는건 해야함 validation 성공, 실패, 예외
service, repository 같이 테스트는 통합테스트 동작확인에 있어서는 좋음 근데 단위 테스트 적으로는.. 단위 테스트 vs 통합 테스트
통합테스트를 안하는 이유. 오류가 어디서 터졌는 지를 모름 둘다 하면 좋긴한데 단위테스트는 로직적으로 중요한 것. 단위테스트가 뭔지. 장점. 단위 테스트 >>> 통합(http로 때워도됨)
jwt토큰 문제 탈취가 되어도 상관없게 만든게 토큰임. setHeader? 상관없음. jwt토큰(보통 header에), 세션-쿠키 방식의 차이를 알아야함 각각의 장단점은 있음. 너무 깊게 알려고는 하지말자. 장단점만 알고있자.