L.O.K

작업한 것 - 개발 SpringBoot에서 제공하는 SimpMessageBroker를 활용하여 채팅서비스를 구현하였다. 그러나 한 가지 문제가 있다. 쿠버네티스 환경에 띄울 것이라 여러 파드에 해당 서버가 띄어지는데, 토픽이 서버 내부에 있다보니 유저의 구독요청이 여러 서버로 로드밸런싱 되어 분산된다. 그러면 어느 한 서버의 토픽에 메시지가 들어가도 다른 서버의 토픽에 구독한 유저는 메시지를 받지 못한다. 이런 문제를 해결하기 위해 처리량이 높고 확장성이 좋은 Kafka를 사용하였다. 1. 채팅방 구독하기 ( STOMP ) 2. 채팅방 입장하기 ( Kafka ) 3. 메시지 전송하기 ( Kafka ) 4. 채팅방 벗어나기 ( STOMP ) 5. 채팅방 구독 취소하기 ( STOMP ) 6. STOMP 세션..

작업한 것 - 프로젝트 백엔드 환경 맞추기 Version Spring Boot: 2.7.7 Java 11 QueryDSL 5.0.0 Package & Naming config util controller PageController ResponseEntity.status().body(); service 인터페이스(PageService) → 구현(PageServiceImpl) repository PageRespository extends JpaRepository dto PageDto vo request response - 개발 1) ERD 및 API 설계에 맞는 스펙으로 채팅서비스 리팩토링 2) 스프링부트 내부에서 제공하는 SimpleMessageBroker는 서버 내부에 topic이 있다. 만약 서버가 2..

작업한 것 - 설계 ( API 설계 ) 배운 것 와이어 프레임과 ER 다이어그램 작성을 하니 API 설계가 뇌피셜이 아닌 근거를 통해 작성하게 된다. 이중 인증/인가 방식 - 서버가 JWT를 발급하고 비밀키를 갖는다. - 클라이언트는 공개키인 JWT와 자신의 UUID를 갖는다. - 서버에 접근하면 서버가 JWT를 파싱하고 UUID를 추출한다. 클라이언트가 전달한 UUID와 일치한지 확인하고 접근을 인가한다. 이슈 채팅내역 유지하려면 redis가 필요해보임 마무리 MSA가 안 될거 같으면 언제든 모놀로식으로 변경!

작업한 것 - 설계 ( ER 다이어그램 ) - 개발 상대방과 채팅 구현 채팅 리스트 구현 대화상대, 최근 대화, 최근 대화 시간, 읽지 않은 메시지 개수 구현 배운 것 - PK와 FK는 내부 JOIN용이다. 클라이언트용 식별자는 UUID로 만들어 제공해야 한다. ( https://americanopeople.tistory.com/378 ) - null 값 if/else 문 안쓰고 처리하기 Optional.ofNullable(findChatRoom).orElse(new ChatRoom("0")); - @Builder 와 @NoArgsConstructor를 같이 쓰려면 @AllArgsConstructor도 선언하면 됨 이슈 - JPA 개념을 많이 잊고 있다 @OneToMany(mappedBy = "chatR..

작업한 것 - 설계 와이어프레임 작성 ( 포스트 상세페이지, 마이페이지, 로그인, 회원가입 ) 로고 및 디자인 컨셉 레퍼런스 조사 - 개발 기초적인 채팅 기능 구현 배운 것 - 리액트 네비게이트로 데이터 넘기는 방법 - 리액트 javascript에 선언된 변수를 html 태그에서 사용하는 방법 : { 변수명 } 으로 데이터를 가져오면 된다. 이슈 - UI 설계 일정이 예상보다 길어지고 있음. - 와이어프레임을 작성하다보니 구현해야 하는 페이지가 생각보다 많다는 것을 알게 됨 마무리 설계는 고통스럽지만... 편한 개발을 위해서 당연히 거쳐야 하는 과정!

작업한 것 와이어 프레임 작성 ( 메인 페이지, 채팅 페이지 ) 로컬 테스트 프로그램 메인페이지 구현 완료 배운 것 UI 설계 과정에서 버튼의 위치, 레이아웃, 헤더, 검색창 등 유저와 개발 방식에 따라 UI가 변할 수 있음을 몸으로 체감할 수 있는 시간이었다. UI만 보고도 백엔드 쪽에서 어떤 작업이 일어나는지를 유추하는 능력이 필요해 보인다. 유추를 해야 프론트엔드와 원활한 소통이 가능해보인다. 이슈 리액트는 객체가 아닌 객체의 요소 별로 렌더링을 한다. - 틀린 코드 {users.map((user, index) => ( {user} ))} - 옳은 코드 {users.map((user, index) => ( Username: {user.username} Email: {user.email} User I..

작업한 것 - 설계 UI 레퍼런스 조사 레퍼런스 별 매칭기능 User Flow 분석하기 우리동네시니어 User Flow 작성 완료 - 개발 리액트 - SpringCloud 로컬 테스트 환경 구성 완료 배운 것 왜 해야 하는가에 대한 고민이 별로 없었던 것 같다. 남이 하니깐 나도 한다는 마인드... 문서 하나하나에도 우리만의 이유가 있어야 함 리액트 페이지 이동 학습 이슈 프로젝트 경험 부족으로 설계과정을 어느 깊이로 해야할지 감이 오지 않음 STOMP 프로토콜의 요청 헤더에 Authorization 헤더 추가가 되지 않음 마무리 설계가 진짜 어려운거구나... 시간 부족... 어디까지 구성해야 하는가?

작업한 것 - 설계 프론트엔드 아키텍쳐 작성 UI 레퍼런스 조사 ( 사람인 - 멘토링 매칭 시스템 ) - 개발 간단한 테스트용 리액트 화면 구현 리액트와 SpringCloud 연동 및 테스트 기초적인 채팅 동작 확인 배운 것 뇌피셜이 아닌 레퍼런스를 근거로 한 접근은 힘이 실린다. 리액트는 훅(Hook)을 이용하여 특정 변수의 상태를 관리하고 상태 변화에 따라 렌더링을 한다. 이슈 설계, 기획, 문서작업의 딜레마 ( 어디까지 레퍼런스를 찾아야 하는가?, 설계와 개발의 시간 분배는 어떻게 해야할까? 리액트에서 채팅방 데이터가 유지되지 않은 현상 발생 마무리 설계는 어렵다....

작업한 것 - 설계 Usecase Usecase 개념 및 작성방법 조사 피그잼 협업 방법 공유 Userflow 유저플로우 개념 및 작성방법 조사 유저플로우 작성 서비스 의문사항 코멘트 - 개발 채팅 기능을 위한 STOMP 원리 학습 채팅 기능 Backend 기초적인 개발 배운 것 Usecase란 무엇인가 피그잼 사용방법 User Flow 함께 작성하기 STOMP 원리 이슈 Usecase의 목적을 제대로 이해하지 못한 것 같음 Usecase는 비교적 사용자나 투자자 등 개발 외적으로 활용되는 문서 -> Usecase에서 Userflow로 선회

- 기간 : 2023.11.20 ~ 20203.11.24 - 기획 내용 - 프로젝트 업무 분담 및 일정 관리 - 세부 내용 기획 Senior 개발자 www.notion.so