캡스톤 설계 [건물별 소통 플랫폼 BBC]/개발 진행 썸네일형 리스트형 개발 진행 정리 및 차후 진행 기본적인 백엔드 API 큰틀 개발을 끝냈다. 세부적으로 가드가 트랜잭션이 안걸려 있는 API체크를 한뒤 본격적으로 프론트 단 개발을 다시 시작할 것이다. . . . 이전에 백엔드 개발을 하며 쌓인 정리 안된 데이터들을 싹 정리하고 postman도 정리를 먼저 해보자. 사용자 2명과 화면 렌더링시 필요한 건물별 게시글 몇개 빼고 모두 삭제 시켰다. 그 과정에서 아래와 같이 업데이트 및 삭제 시 관계가 연결된 테이블에 대한 설정도 각각 세팅했다. 더보기 게시글 의 댓글 갯수 API 댓글 생성과 댓글 갯수 +를 트랜잭션으로 묶기 댓글 카운트가 잘 생성 된다. 댓글 삭제와 댓글 갯수 감소를 트랜잭션으로 묶기 잘 반영된다. 더보기 자신이 작성한 게시글과 댓글 수정 삭제 가능케하는 가드 생성 자신이 작성한 글만 수정 및 삭제 가능. 자신의 댓글 아니면 수정 삭제 불가능 더보기 존재하는 게시글인지 체크하는 미들웨어 게시글이존재하는지 확인하는 함수 미들웨어 미들웨어 컨트롤러에 등록 이제 존재하지 않는 postid를 조회하면 오류가 난다. 더보기 comment 모듈 리팩토링 현재 나의 서비스의 모든 댓글들은 게시물에 귀속이 되어있다. 그래서 컨트롤러 요청 url과 엔티티에 대해 그에 맞게 리팩토링을 하고자 한다. 관계를 생각해서 다시 리팩토링 초기 진입 url 수정 댓글 페이지 네이션 dto생성 댓글 가져오기 페이지네이션 적용 코드 작성 완 개별 댓글들 가져오기 완 댓글 생성 리팩토링 완 댓글 수정하기 코드 완 댓글 삭제하기 코드 완 더보기 소켓 채팅시 사용자 인증 방법 리팩토링 소켓은 한번 연결이 되면 헤더를 바꿀 수가 없다. 그래서 소켓 연결을 한 뒤 토큰이 만료가 되면 서비스이용에 차질이 생긴다. 그러면 restAPI처럼 그냥 다시 로그인을 하면 되는것 아닌가? 싶겠지만 갱신이 되지 않는다. . . . . 물론 이전 방법처럼 하나하나의 소켓 이벤트마다 가드를 붙여서 사용을 해도 되며 그렇게 서버를 유지하는 것도 있긴 하지만 리소스를 많이 잡아 먹어 효율적이지 않다. . . 또한 소켓의 특성중 재미있는것이 한번 연결된 소켓은 클라이언트와 서버는 그 하나의 소켓으로만 소통을 한다. 즉 처음 연결된 그 소켓에 사용자 정보를 넣으면 많은 리소스를 잡아먹지 않게 설계할 수 있는것이다. 이렇게 처음 연결할때만 토큰을 인증하면 그 이후 는 자동으로 해당 사용자의 정보를 사용할 수 있다... 더보기 채팅에 가드 적용하기 토큰에서 키 제외한 value만 가져오는 함수 생성 사용자 이메일로 사용자 정보 가져오는 함수 생성 req가 아닌 socket에 사용자 정보와 토큰 넣기 socket을 콘솔러 찎어보면 사용자 정보와 토큰이 잘 나온다 ! 더보기 gateway에서의 validationPipe gateway는 main.ts에서 글로벌로 설정한게 적용아 안되서 따로 하나씩 적용해줘야한다. validation에 걸리긴 했지만 그래도 에러가 나온다. 그 이유는 기본적으로 nest에서 wsException은 httpException을 상속하지 않기 떄문에 필터에 걸리지않다. 그래서 추가 작업을 더 해줘야한다. 새로운 추가 에러 필터 생성 그럼 이제 에러 처리가 잘 된다 ! 더보기 이전 1 2 3 4 5 6 ··· 12 다음
