Java/Spring TIL

인터넷 브라우저(클라이언트) 와 서버가 데이터를 주고받는 통신 방법인 HTTP(HyperText Transfer Protocol) 는 결국,Web 기반에서 동작하기 때문에 네트워크에 대한 지식이 필수복잡한 인터넷 세상에서 컴퓨터와 컴퓨터끼리 데이터를 주고받기 위하여 정

Spring 입문 2주차Spring 입문 3주차MVC 레이어 관심사 분리

스프링 구조가 조금 헷갈려서 짚고 넘어갔다.

IDE클라이언트-서버

다음은 예외처리의 흐름을 도식화한 것이다.이 부분에서 예외가 발생하지 않을시 '정상 응답 반환' 하는 부분에서 이해가 가지 않는 부분이 있었다.ResponseEntity<> 를 쓰는 이유 HTTP 상태 코드와 응답 바디를 함께 제어할 수 있기 때문이다.따라서 예외

객체 생성을 더 명확하고 읽기 쉽게 하기 위해Builder 는 유연하지만 쓰기 번거로움 --> of() 는 Builder 를 감싸는 편의 메서드 역할을 함static: 클래스 레벨에서 접근할 수 있게 함 (new 없이 사용 가능)of(): 명확한 의미 전달 + Buil

: 클래스의 인스턴스를 오직 하나만 생성하도록 보장하는 디자인 패턴즉, "같은 객체를 계속 새로 만들지 말고, 한 번 만든 것을 재사용하자!" 라는 뜻인스턴스는 단 한 번만 생성됨전역적으로 공유됨메모리 효율이 좋고, 객체 생성 비용 절감Spring 은 기본적으로 모든

주로 HTTP 요청/응답 레벨에서의 처리가 필요할 때 사용ex) 인증 체크, API 로깅, CORS주로 비즈니스 로직 내부에서의 공통 처리에 적합ex) 메서드 실행 시간 측정, 트랜잭션, 예외 감싸기Interceptor 로 API 요청을 기록하고,AOP 로 내부 서비스

클라이언트가 요청하면,DispatcherServlet 이 어떤걸 요청했는데 핸들러를 조회한다는 것이 어떤 메서드를 실행할지 컨트롤러에서 메서드를 찾기HandlerMapping 컴포넌트 사용대표적인 구현체 RequestMappingHandlerMapping이 객체가 @R

다른 조 발표 영상을 보다가 '룩업 테이블' 이라는 생소한 용어를 접해 알아보게 됐다. 룩업 테이블(Lookup Table) > 값을 빠르게 찾기 위한 미리 만들어 놓은 표 > - 특정 입력값에 대해 미리 계산된 결과 값을 저장해 놓고, 나중에 해당 값을 빠르게 가

@RestController, @Controller 모두 스프링 프레임워크에서 웹 요청을 처리하는 클래스에 사용하는 애너테이션반환 방식과 목적이 다름전통적인 MVC 패턴의 컨트롤러에 사용반환 타입이 String 이면 뷰(View) 이름으로 처리됨데이터를 반환하려면 @R

데이터베이스 운영의 번거로운 작업을 AWS가 대신 관리해주는 서비스즉, DB 설치, 백업, 보안, 복구 등 서버 관리 부담을 줄여주고,✅ 개발자는 비즈니스 로직에만 집중할 수 있게 해줌서버에 Ubuntu 설치 → MySQL 수동 설치 → 사용자/포트 설정 → 보안설정…

ZSet(정렬된 집합)은 각 원소에 점수(score)를 부여하고 자동 정렬이 되는 Redis 자료구조입니다.사용이유:인기 검색어는 점수(검색 횟수)에 따라 실시간으로 정렬되어야 하며, 상위 N개를 빠르게 조회해야 합니다. ZSet은 이를 위해 설계된 구조입니다.핵심 명

Spring에서 WebSocket + STOMP 프로토콜을 통한 pub/sub 메시징 기능 활성화하는 어노테이션👉 @Configuration 클래스에서 사용👉 WebSocket을 통한 메시지 처리 기능을 활성화👉 STOMP (Simple Text Oriented

팀 컨벤션이 확실하게 있는데, 웹소켓으로 기능을 구현하고자 하니 지킬 수 없게되었다.그런데 그게 정상이라고 한다.WebSocket용 코드에서는 팀 REST 컨벤션 (BaseResponse 래핑 등)을 "그대로 적용하려고 억지로 할 필요 없음"→ WebSocket은 @M

일반적인 HTTP 요청:매번 HTTP 헤더에 Authorization(JWT) 넣음SecurityFilter가 처리함WebSocket:최초 핸드셰이크(Handshake) 요청은 HTTP로 가지만연결 후에는 별도 TCP 소켓 통신SecurityFilter는 작동 안 함!

WebSocket 기반 실시간 채팅 시스템STOMP + SockJS를 활용한 메시지 송수신채팅방 생성, 입장, 메시지 조회, 메시지 전송JWT 기반 인증 처리 (핸드셰이크 단계)WebSocket 연결 시 JWT 토큰을 HandshakeInterceptor에서 검증STO

🎤 5분 브리핑 발표 대본: 실시간 그룹 채팅 시스템 구현🟡 1. 문제 정의 (Why)안녕하세요. 저는 이번 프로젝트에서 WebSocket 기반의 실시간 그룹 채팅 시스템을 구현했습니다.이 기능이 왜 필요했는지를 먼저 말씀드리면,저희 서비스에는 그룹 기능이 존재했지

Spring 은 @Transactional 이 붙어있다고 해서, 메서드 내 모든 코드가 "커밋 이후" 에 실행되는 것은 아니다. 스프링의 트랜잭션은 메서드 본문 전체를 하나의 트랜잭션 경계 안에서 실행 메서드가 정상 종료(return)되면 커밋 순으로 동작하기 때

읽음(“read receipt”) 상태를 WebSocket 이벤트로만 처리한다면, 클라이언트가 실시간 연결을 못 잡았을 때는 누락될 수 있다. 그래서 보통 이 둘을 함께 제공한다고 한다. 1. WebSocket: 실시간 “누가 읽었는지” 즉시 푸시 알림 채팅 화면

하나의 발신자가 특정 메시지를 여러 수신자에게 동시에 전송하는 방식일반적으로 네트워크나 메시징 시스템에서 “1:N” 통신 패턴을 구현할 때 사용되며, WebSocket 기반 채팅 애플리케이션에서는 다음과 같은 방식으로 동작함Unicast(유니캐스트): 특정 한 대의 클

개선 대상: 채팅방 목록 조회, 읽음 상태 처리, 트랜잭션 후 브로드캐스트 로직주요 목표: N+1 쿼리 제거 및 코드 중복 최소화, 응답 속도 개선, 코드 가독성 향상핵심 결과: 채팅방 목록 조회 시 쿼리 수 1건으로 감소, Broadcast 로직 중복 50% 축소,

답변: REST는 채팅방 생성, 참가자 목록 조회 등 CRUD성 요청 처리에 적합하고, WebSocket은 메시지 전송/수신처럼 실시간성이 중요한 기능에 적합합니다. 두 방식을 병행하면 효율적인 자원 관리와 사용자 경험을 동시에 달성할 수 있습니다.답변: STOMP는

QueryDSL을 사용하는 이유는 타입 안전성, 가독성, 유지보수성이 뛰어난 동적 SQL 쿼리 생성 도구이기 때문입니다.컴파일 시점에 쿼리 오류를 잡을 수 있음 (ex. 잘못된 필드명, 오타 등)일반 JPQL이나 String 기반 쿼리에서는 런타임 에러가 날 수 있지만

“쎈 쿼리”는 일반적으로 개발자들이 직접 SQL을 작성하는 방식, 즉 순수 SQL(=Native SQL)을 사용할 때 쓰는 은어JPA나 QueryDSL 같은 추상화된 ORM 도구를 사용하지 않고, 직접 SQL을 작성해서 DB에 날리는 쿼리JPA, QueryDSL은 추상

웹소켓은 기본적으로 TCP 기반의 지속적인 연결 상태를 유지하지만, 연결이 실제로 살아있는지는 네트워크 단절, 브라우저 종료, 서버 다운 등 다양한 원인으로 예기치 않게 끊길 수 있기 때문에, 명시적으로 연결 상태를 확인하는 로직이 필요합니다.이를 확인하는 방법으로는

전체 흐름 → 구체 처리 → 이유/근거" 형식유저가 채팅방에 입장하면, 서버는 WebSocket 핸드셰이크 단계에서 JWT를 검증하고 사용자 정보를 WebSocketPrincipal로 세션에 매핑합니다. 이후 REST API를 통해 채팅방 멤버로 등록되며, SimpMe