YoungSoo

문제 발생 팀원 중 하나가 Flutter로 개발 중인 Furry-Friend 프로젝트에서 백엔드 서버의 WebSocket Stomp와 연결하는 과정에서 오류를 겪었습니다. 문제 해결 과정 처음에는 Front-end를 Next.js로 개발한 부분에서 문제가 없어 보여 Flutter 코드를 의심했지만, 팀원이 많은 라이브러리와 방법을 시도해도 문제가 해결되지 않았습니다. 그러던 중 Flutter 및 Dart와 WebSocket 연결에 관한 문제 해결을 위한 글을 찾아보았습니다. 이 글을 통해 다른 개발자가 비슷한 문제를 겪었으며 NGINX를 프록시로 사용하고 있었다는 사실을 알게 되었습니다. 그리고 해당 글에서 NGINX 설정에 다음 코드를 추가해야 한다는 정보를 얻었습니다. proxy_http_versio..

Test Driven Developmen 프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현 과정을 주도하도록 하는 방법론 Red - Green - Refactor 순으로 개발 1. Red - 실패하는 테스트 작성 2. Green - 테스트를 통과하는 최소한의 코딩 3. Refactor - 구현 코드 개선과 테스트 통과 유지 이러한 사이클을 통해 TDD를 했을 땐 1. 복잡도가 늦은, 테스트 가능한 코드로 구현할 수 있음. 2. 쉽게 발견하기 어려운 엣지 케이스를 놓치지 않게 해준다. 3. 구현에 대한 빠른 피드백을 받을 수 있다. 4. 과감한 리팩토링이 가능해진다. 이러한 장점들을 확인할 수 있습니다. 반대로 선 기능 구현 후, 테스트를 작성했을 땐 1. 테스트 자체의 누락 가능성 2. 특정 ..

지난 게시물에서는 WebSocket과 Stomp를 사용해서 pub/sub 방식으로 채팅 서비스를 개발했습니다. 이번 시간에는 이전 채팅 조회와 많은 고민이 있었던 읽음 처리에 대한 글을 작성하려고 합니다. 이전 채팅 조회 이전 채팅을 조회하는 기능에서 요구되는 사항은 아래와 같았습니다. 1. 채팅방 2. 안 읽은 채팅의 개수 3. 마지막 채팅 내용 저는 SQLD 자격증을 보유하고 있어서 세 개를 조회하는 쿼리를 작성하는 것은 어렵다고 생각하진 않았습니다. 하지만 조인과 서브쿼리를 사용해 요구하는 데이터를 조회하게 되었는데, 이 과정에서 N+1 문제와 고민이 생기게 되었습니다. N+1 문제는 하위 엔티티를 조회할 때 상위 엔티티가 같이 조회되는 상황을 말합니다. 이것을 해결하는 방법으로는 지연로딩, 패치 ..

지난 게시물에서는 WebSocket과 Stomp를 사용해서 pub/sub 방식으로 간단한 채팅을 구현하는 실습을 진행했습니다. 이번 게시물에서는 웹 소켓과 Rest API를 통해서 구현한 기본적인 채팅 서비스를 구현해 보겠습니다. 사용자 입장의 채팅 서비스 채팅 서비스를 사용자 입장에서 처음 채팅을 시작할 때 게시글에 있는 채팅 보내기를 통해 채팅방을 구성하게 됩니다. 이때 채팅방과 채팅 참여자가 테이블에 등록이 됩니다. 채팅 목록을 조회하고 채팅방을 선택할 때 WebSocket 연결을 하고 Stomp를 통해 pub/sub 형식의 채팅이 이어지게 됩니다. 이때, 채팅방 고유 번호를 사용해 각 채팅방마다 발신자와 구독자에게만 메시지를 전달하게 됩니다. 필요 의존성 추가 // Chat implementati..

WebSocket에 대해 알아보자! 웹소켓이란, TCP 접속에 전이중 통신 채널(양방향 통신 채널)을 제공하는 컴퓨터 통신 프로토콜이다. 이를 사용하면 서버와 브라우저 간에 연결된 상태로 데이터를 교환할 수 있습니다. 데이터는 패킷(packet)의 형태로 전달이 되고, HTTP 요청을 하지 않고 양방향 통신이 이루어집니다. 패킷이란? 네트워크 통신에서 데이터를 전송하는 최소 단위 WebSocket 패킷은 헤더(Header)와 페이로드(Payload)로 구성됩니다. 헤더에는 패킷의 메타데이터와 제어 정보, 패킷의 길이, 압축 여부, 메시지 타입 등의 정보가 헤더에 포함될 수 있습니다. 페이로드는 실제 전송되는 메시지, 이벤트 데이터, 상태 정보 등이 페이로드에 포함됩니다. 왜 WebSocket을 사용해? ..

왜 갑자기 CQRS를 도입해요? CQRS는 명령과 조회를 분리함으로써 성능 향상 및 결합도가 낮아지는 효과를 기대할 수 있습니다. 채팅 서비스를 구현하게 된다면 일반 게시글이나 댓글에 비해 더 많은 양의 데이터가 저장될 것이라고 생각했습니다. 이를 위해 명령과 조회를 분리하고 조회에 성능이 좋은 NoSQL을 일관성과 정확성이 중요한 데이터 처리, 복잡한 관계 처리, 안정성을 보장하는 RDB를 조합하여 최적의 데이터베이스 환경을 구성하려고 합니다. CQRS 도입이 필요할까요? CQRS 패턴은 모든 상황에 적합한 해결책은 아닙니다. 사용 여부는 프로젝트의 요구사항과 복잡성에 따라 결정되어야 합니다. 오히려 단순한 CRUD 작업이 주로 이루어지는 간단한 애플리케이션에는 비효율적입니다. 근데 사실 한 번 써보고..

채팅 서비스를 개발하기 전에 소프트웨어 생명주기(Software Development Life Cycle - SDLC)에 맞춰 진행하려고 합니다. 이 글은 생명주기의 요구사항 분석 및 설계를 작성해 보았습니다. 요구사항 분석 필요 기술 스택 1. Java 2. Spring Boot 3. MySQL 4. MongoDB 5. WebSocket 6. Kafka 우선 개발 기능 1. 일반적인 채팅 서비스 (메시지 조회, 저장, 삭제, 읽음 표시) 2. 명령과 조회를 분리하기 위한 CQRS (Kafka) 추가 개발 기능 3. 알림 서비스 (Kafka를 통해 알림 생성) 테이블 명세 API 명세

프로젝트 개발을 위해 프런트엔드 개발자 분과 협업을 하는 중에 이와 같이 중복으로 헤더가 생성되는 오류가 발생했습니다. 이를 해결하기 위해 CORS에 대해 간단하게 알고 가려고 합니다. CORS(Cross-Origin Resource Sharing) 란? CORS는 다른 출처의 자원을 공유하는 것을 허용하는 것입니다. 동일 출처 정책(same-origin policy)에 의해 어떤 출처에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안 방식이 적용되어 CORS를 통해 허용해 주어야 가능합니다. 다른 출처는 아래의 세가지 경우 정도로 생각할 수 있습니다. 프로토콜이 다른 경우(예시 : http/https) 도메인이 다른 경우 포트번호가 다른 경우 SOP(동일..