당니의 개발자 스토리

이전 글에서는 프레임워크와 라이브러리의 차이, 그리고 IoC에 대해 정리했다. 이번 글에서는 Spring이 실제 DB에서 반복 코드를 어떻게 줄여주는지 정리해보려고 한다!! Spring을 처음 배우면스프링은 개발자가 비즈니스 로직에 집중할 수 있게 해준다 라는 말을 많이 들어봤을 것이다..이게 뭔 말이지 싶은데,JDBC와 트랜잭션을 보면 더 잘 이해할 수 있다. 자바 프로그램에서 데이터를 저장하거나 조회하려면 DB와 연결해야 한다.이때 기본적으로 사용하는 기술이 JDBC다. JDBC는 Java Database Connectivity의 약자이고자바에서 데이터베이스에 연결하기 위한 기본 방법이다. JDBC를 사용하면 DB에 연결되니까자바 코드에서 SQL을 실행할 수 있게 된다!!예를 들어 회원 목록을 조회하..

프레임워크와 라이브러리는 둘 다 개발을 편하게 해주는 도구처럼 보인다.그래서 처음 배우면 둘이 비슷하게 느껴진다. 하지만 둘의 차이는 분명하다!! 라이브러리는 내가 필요할 때 가져다 쓰는 도구이고,프레임워크는 내가 그 틀 안에 맞춰서 코드를 작성하는 구조다. 가장 중요한 차이는 제어의 흐름(IoC)이다.라이브러리는 내가 불러서 호출한다(도구 같은 느낌)프레임워크는 프레임워크가 내 코드를 호출한다(양식, 틀 같은 느낌)이 차이를 이해하면 프레임워크와 라이브러리의 구분이 훨씬 쉬워진다. 라이브러리는 내가 필요할 때 꺼내 쓰는 도구다.예를 들어 Java에서 정렬 기능이 필요하다고 해보자.import java.util.*;public class Main { public static void main(Str..

REST와 gRPC의 차이와 실제 코드 흐름gRPC는 다른 서버의 메서드를 내 코드에서 호출하듯이 사용한다 REST는 이렇게 생겼다.GET /users/1 gRPC는 이렇게 생겼다.stub.getUser(request); 겉으로 보면 그냥 메서드 호출이지만,실제로는 네트워크를 타고 서버에 갔다 온다. stub 호출→ request 직렬화→ 네트워크 전송→ 서버 메서드 실행→ response 반환 Spring에서 구조는proto 파일 작성코드 자동 생성서버에서 구현클라이언트에서 stub 호출 예를 들어GetUserResponse res = stub.getUser(request); 이 한 줄이 실제로는 서버 호출이다. gRPC에서 해시키를 담을 수 있다이 표현은 상황에 따라 다르게 쓰인다.보통은 두 가지 중..

Filter 적용 범위와 실행 시점Filter는 만들었다고 자동으로 알아서 적용된다고 생각하면 안 된다!!!어디에 적용할지 설정을 해줘야 한다.이걸 Filter Mapping이라고 한다. 대표적으로 두 가지 방식이 있다.1. 특정 URL만 적용@WebFilter("/login") → /login 요청에만 필터 실행2. 전체 요청 적용 @WebFilter("/*") → 모든 요청에 필터 실행/login/board/api/*정적 파일까지 다 포함정적 파일은 css나 js, png 파일들을 말한다.예를 들어 로그인 필터 만들었는데, /*으로 해서 정적 파일까지 다 포함했다고 하자.로그인 안됨 → 차단 이런 경우, css도 막히고 이미지도 막혀서 결국 로그인이 안됐다고 화면이 깨져버리는 문제가 생긴다.../*그..

Filter 개념과 ControllerHelper의 차이Front Controller를 쓰면 공통 로직을 한 곳으로 모을 수 있다.그런데 여전히 한계가 있다.. 왜냐하면 Controller 안에서만 공통 처리가 가능하기 때문이다.예를 들어 이런 상황을 보자.로그인 여부 체크요청 로그 기록XSS 방지인증 토큰 검사이건 특정 컨트롤러가 아니라 모든 요청에 적용되어야 하는 기능이다.그래서 나온 게 Filter다. 이게 뭔 말인가?Filter는 요청이 서블릿에 들어가기 전에 가로채서 처리하는 구조이다.즉,클라이언트 → 서버 → (Filter) → (Servlet/Controller) → 응답이런 흐름으로 처리된다. 따라서, Filter는 Controller보다 앞에서 동작한다.근데, 만약 로그인을 안했으면 막아..

기존 Servlet 방식의 한계와 Front Controller 패턴처음에 서블릿으로 웹을 만들 때는 요청 하나마다 서블릿 하나씩 만드는 구조로 시작하게 된다.예를 들어 /login, /join, /gugu 이런 식으로 요청이 늘어날 때마다 서블릿도 계속 늘어난다.문제는 여기서부터 발생한다.로그 처리, 파라미터 출력, 인증 체크 같은 공통 로직이 모든 서블릿에 반복된다.그리고 요청 흐름도 서블릿마다 제각각이라 유지보수가 점점 어려워진다.이걸 한 번에 해결하려고 나온 게 Front Controller 패턴이다.핵심은 하나다.모든 요청을 하나의 서블릿으로 몰아넣고, 그 안에서 분기한다.예를 들어 /main 하나만 만들고 모든 요청을 여기에 보내는 방식이다. @WebServlet("/main")public c..