캡스톤 설계 [건물별 소통 플랫폼 BBC] 썸네일형 리스트형 전반적인 게시판 관련 로직 및 코드 리팩토링 우선 위 사진은 리팩토링 전 프론트엔드 root 디렉토리 이고 오른쪽은 리팩토링 후 간결해진 root 디렉토리이다. . . board기반의 데이터 베이스를 생성하여 게시판 의 id와 이름을 저장했다. 그리고 이젠 url에 게시판 이름을 토대로 url을 생성하는게 아닌 boardid기반으로 url을 생성하였다. . . . 이전에는 각 게시판 url페이지를 각각 렌더링을 시켰다. 왼쪽 코드를 각각 게시판 별로 14개를 만들었지만 현재는 오른쪽과 같이 nextJs의 slug를 사용하여 아주 약간만 더 길지만 14개의 파일이 하는 기능을 구현하였다. 뿌듯하다. 위 코드는 slug를 활용하여 url을 해당 url을 가져와서 로직을 수행하게 만들었다. 그리고 백엔드 단의 로직도 추가 하였다. 중요한 점으로 이전에 .. 더보기 게시판 entity 생성 프론트단 상세 페이지 개발에 앞서 게시판 별로 모두 각각 개발하는건 너무나도 시간이 오래걸리고 비효율 적이라 생각하여 게시판 테이블을 만들어 각각의 id를 사용해서 slug를 활용해 보고자 한다. . . 게시판의 이름만 속성으로 가지고 있다. . . . 각각의 게시판을 enum을 사용해도 될것 같지만 차후 각각의 학교 별로 게시판을 다르게 사용할것도 가정하여 테이블을 따로 만들었다. . . . 현재 애브리타임 또한 각각의 특정 게시판과 게시글마다 아래와 같이 특정한 숫자값으로 라우팅 처리 한다. . . . 그래서 굳이 내부 로직을 자세히 뜯어 보진 안더라도 이와 비슷하게 구현을 해보고자 한다. 더보기 개발 진행 정리 및 차후 진행 기본적인 백엔드 API 큰틀 개발을 끝냈다. 세부적으로 가드가 트랜잭션이 안걸려 있는 API체크를 한뒤 본격적으로 프론트 단 개발을 다시 시작할 것이다. . . . 이전에 백엔드 개발을 하며 쌓인 정리 안된 데이터들을 싹 정리하고 postman도 정리를 먼저 해보자. 사용자 2명과 화면 렌더링시 필요한 건물별 게시글 몇개 빼고 모두 삭제 시켰다. 그 과정에서 아래와 같이 업데이트 및 삭제 시 관계가 연결된 테이블에 대한 설정도 각각 세팅했다. 더보기 게시글 의 댓글 갯수 API 댓글 생성과 댓글 갯수 +를 트랜잭션으로 묶기 댓글 카운트가 잘 생성 된다. 댓글 삭제와 댓글 갯수 감소를 트랜잭션으로 묶기 잘 반영된다. 더보기 자신이 작성한 게시글과 댓글 수정 삭제 가능케하는 가드 생성 자신이 작성한 글만 수정 및 삭제 가능. 자신의 댓글 아니면 수정 삭제 불가능 더보기 존재하는 게시글인지 체크하는 미들웨어 게시글이존재하는지 확인하는 함수 미들웨어 미들웨어 컨트롤러에 등록 이제 존재하지 않는 postid를 조회하면 오류가 난다. 더보기 comment 모듈 리팩토링 현재 나의 서비스의 모든 댓글들은 게시물에 귀속이 되어있다. 그래서 컨트롤러 요청 url과 엔티티에 대해 그에 맞게 리팩토링을 하고자 한다. 관계를 생각해서 다시 리팩토링 초기 진입 url 수정 댓글 페이지 네이션 dto생성 댓글 가져오기 페이지네이션 적용 코드 작성 완 개별 댓글들 가져오기 완 댓글 생성 리팩토링 완 댓글 수정하기 코드 완 댓글 삭제하기 코드 완 더보기 소켓 채팅시 사용자 인증 방법 리팩토링 소켓은 한번 연결이 되면 헤더를 바꿀 수가 없다. 그래서 소켓 연결을 한 뒤 토큰이 만료가 되면 서비스이용에 차질이 생긴다. 그러면 restAPI처럼 그냥 다시 로그인을 하면 되는것 아닌가? 싶겠지만 갱신이 되지 않는다. . . . . 물론 이전 방법처럼 하나하나의 소켓 이벤트마다 가드를 붙여서 사용을 해도 되며 그렇게 서버를 유지하는 것도 있긴 하지만 리소스를 많이 잡아 먹어 효율적이지 않다. . . 또한 소켓의 특성중 재미있는것이 한번 연결된 소켓은 클라이언트와 서버는 그 하나의 소켓으로만 소통을 한다. 즉 처음 연결된 그 소켓에 사용자 정보를 넣으면 많은 리소스를 잡아먹지 않게 설계할 수 있는것이다. 이렇게 처음 연결할때만 토큰을 인증하면 그 이후 는 자동으로 해당 사용자의 정보를 사용할 수 있다... 더보기 이전 1 2 3 4 5 6 ··· 15 다음
