Steady and right

클라리언트가 웹브라우저에 접속하여 서버에 요청을 하게 되면 HTML을 응답받아 서비스를 이용하게 된다 이때 HTML을(웹브라우저가) 구현하는 두가지 방식이 있는데 바로 CSR(Client Side Rendering)과 SSR(Server Side Rendering)이다 CSR (클라이언트 사이드 렌더링) 웹브라우저가 서버에서 API로 데이터를 받아 그 값들을 자바스크립트 로직에 맞게 동적으로 렌더링하여 사용자에게 보여주는 것이 CSR이다 CSR의 경우 HTML과 static 파일만 받게 되면 나머지는 자바스크립트를 통해 동적으로 렌더링 하기 때문에 사용자의 UX가 뛰어나고 서버에 요청하는 횟수가 훨씬 적기 때문에 서버의 부담 또한 덜하다 하지만 HTML과 static을 꼭 받아야 하기 때문에 초기속도가 ..

서블릿&서블릿 컨테이너의 글에서 WAS가 멀티스레드를 자동으로 지원 및 관리한다고 했는데 직접 이 멀테쓰레드의 코드를 짤 상황은 없겠지만 이 멀티쓰레드가 어떤 것인지 좀 더 자세하게 알아보고자 한다 Multi-Thread(멀티 스레드) 서블릿을 호출하는 것이 바로 스레드이다 스레드는 애플리케이션 코드를 하나하나 순차적으로 실행하며 한 번에 하나의 코드라인만 실행하게 된다 그렇기 때문에 여러 가지 요청을 동시에 처리를 하려면 스레드를 추가적으로 생성하여 실행하는데 이것이 바로 멀티스레드이다 WAS가 기본적으로 스레드를 자동적으로 만들어주지만 스레드의 경우 생성의 제한이 없기 때문에 너무 많은 요청이 들어오게 되면 cpu 혹은 메모리의 임계점을 넘겨버려 서버가 죽어버릴 수 있다 또한 하나의 코어가 하나의 스..

Web Scope 웹 스코프는 웹 환경에서만 동작하는 특징을 가지고 있으며 프로토타입 스코프와 다르게 종료 시점까지 스프링 컨테이너가 관리하기 때문에 종료 메서드를 호출해준다 웹 스코프를 사용하는 이유는 클라이언트에게 서비스를 제공하다 문제가 생겼을 때 보통 로그를 확인하여 디버깅을 진행한다 하지만 이때 동시에 접속한 여러 고객들의 요청이 뒤죽박죽 섞여 있으면 아주 힘든 상황이 될 것이다 그래서 공통적인 포맷으로 깔끔하게 로그들이 정리되어서 출력되도록 해주는 것이 웹 스코프의 역할이다 웹 스코프의 종류는 아래와 같이 다양하다 1. request HTTP 요청에 하나가 들어오고 나갈 때까지 유지되는 스코프이다 각각의 HTTP요청 마다 별도의 빈 인스턴스가 생성되고 관리된다 2. session HTTP Se..

데이터베이스나 커넥션 풀, 네트워크 소켓처럼 애플리케이션이 시작하는 시점에 연결을 미리 해야 하는 상황이 있다 이때 종료시점에 맞춰 연결을 모두 종료하려면 객체의 초기화와 종료 작업이 필요하다고 한다 초기화 같은 작업은 빈 객체를 생성하고 의존관계의 주입이 끝난 다음에야 필요한 데이터를 사용할 수 있도록 준비가 된다 즉 개발자가 언제 의존관계가 주입이 되는지를 알아야 한다 Bean 생명주기 의존관계를 알기 위해서는 우선 빈의 생명주기를 알아야 한다 스프링 빈은 대략적으로 아래와 같은 생명주기를 가지고 있다 (초기화 콜백: 빈이 생성되고 빈의 의존관계 주입이 완료된 후의 호출) (소멸 전 콜백: 빈이 소멸되기 직전의 호출) 이때 생성자 주입의 경우 스프링 빈이 생성됨과 동시에 의존관계가 주입이 되며(파라미..

스프링 컨테이너에 빈을 등록하기 위해서는 @Bean이나 XML의 을 통해서 직접 등록할 수도 있지만 수많은 스프링 빈을 등록할 때는 매우 비효율적이다 Component @Bean이나 을 사용하지 않고 빈을 등록할 수 있게 스프링은 Component Scan(컴포넌트 스캔)을 제공하는데 말 그대로인 컴포넌트 '스캔'을 위해서 '컴포넌트'를 먼저 등록해주어야 한다 @Component public class MemoryMemberRepository implements MemberRepository {} 이렇게 등록된 컴포넌트들은 컴포넌트 스캔이 이 어노테이션의 여부를 보고 스프링의 빈으로 등록하게 된다 Component Scan 컴포넌트 스캔이 어노테이션들을 조회할 기준은 base package를 통해 결정된..

스프링으로 주로 개발되는 웹 애플리케이션의 경우 대부분 여러 고객이 동시 요청을 하는 상황이 발생되게 된다 이때 요청마다 새로운 객체를 생성한다면 수많은 객체를 만들어야 할 것이고 트래픽이 많아지게 되면 결과적으로는 굉장히 비효율적인 구조가 될 것이다 이렇게 객체를 새로 만드는 것보다 이미 존재하고 있는 객체를 조회하는 것이 메모리적으로는 비교할 수 없을 정도로 효율적이라고 한다 이로써 객체를 새로 만들지 않고 공유하게 해주는 싱글톤 패턴을 사용하면 문제점을 해결할 수 있다 Singleton Pattern(싱글톤 패턴) 싱글톤 패턴은 클래스의 객체를 딱 1개만 생성하여 이를 공유(조회)할 수 있게 해준다 public class SingletonService { // static 영역에 미리 객체를 1개 ..