Proxy의 역할 proxy란, '대리'라는 뜻입니다. 그리고 이 용어는 IT 분야 곳곳에서 다양하게 사용됩니다. 예를 들어 Proxy pattern, Spring proxy, Network proxy 등이 있는데요, 이번 아티클에서 살펴보고자 하는 부분은 Network proxy입니다. 개발자의 길을 걷다보면 많은 부분에서 공통적으로 접하게 되는 개념이 있습니다. 바로 추상화입니다. 추상화란, 불필요한 차이점을 배제하고 공통점만을 추출하는 작업을 의미합니다. 이런 추상화가 왜 중요할까요? 복잡도를 획기적으로 낮춰주기 때문입니다. 제가 추상화에 대한 이야기를 한 이유는 Network Proxy도 하나의 추상화 메커니즘이기 때문입니다. 그럼 어떤 것을 추상화하느냐? 바로 네트워크 통신 자체를 추상화합니다...
Web Server란? 웹 서버는 1. 하드웨어 웹 서버, 2. 소프트웨어 웹 서버로 분류됩니다. 하드웨어 웹 서버의 경우는 웹 서버가 설치되어 있는 컴퓨터를 의미하며 소프트웨어 웹 서버의 경우 클라이언트로부터 HTTP 요청을 받아 정적 컨텐츠(html, css, png 등)를 제공하는 프로그램을 의미합니다. 그리고 대표적인 소프트웨어 웹서버로는 Apache, Nginx가 있습니다. 웹 서버는 정적 컨텐츠를 전달한다고 했는데요, 이처럼 웹 서버의 주된 목적은 웹 페이지, 이미지 파일 등을 클라이언트로 전달하는 것입니다. 그렇다면 동적 컨텐츠에 대한 HTTP 요청이 들어왔을 때의 처리는 누가 해주는걸까요? 바로 WAS입니다. WAS(Web Applicaition Server) WAS는 DB 조회나 다양한..
스프링과 데이터베이스 개념을 처음 접하고나서부터 가장 큰 고민은 '도메인 엔티티에 ID를 부여하는 기준은 무엇인가?' 이었습니다. 그리고 레벨 2를 마쳐가는 지금, 어느정도 저만의 생각이 확립된 것 같아 기록의 목적으로 아티클을 작성해두고자 합니다. 추후에 '이때는 이런 생각을 했었구나!' 라는 생각이 들 수 있도록이요. 따라서 아래 내용은 주관적인 생각이 대부분입니다. ID의 필요성영속성 개념을 접하게되면 겪는 가장 큰 문제점은 객체지향과 영속화 사이의 괴리감(패러다임의 불일치)입니다. 분명 객체지향적으로 짜야 하는데, 데이터 중심 설계를 하게 되는 경우도 많고 도메인 엔티티와 영속성 엔티티를 분리하기가 어려운 등... 여러 문제들이 발생합니다. 그리고 이런 괴리감이 드는 이유 중 하나가 도메인 엔티티..
이번 장바구니 협업 미션을 진행하면서 배포를 해보게 되었고 https라는 개념도 처음 다루게 되었습니다. 이번 아티클을 통해 https의 개념은 대략적으로 무엇인지, 어떻게 ec2 기반 서버에 적용할 수 있는지 알아보고자 합니다. HTTP, HTTPS? HTTPS(Hyper Text Transfer Protocol Secure)이란, HTTP에서 SSL 혹은 TLS라고 불리는 암호화 방식이 추가된 것입니다. HTTP는 바디, 헤더등을 암호화할 수 없어서 민감한 정보까지도 순전히 드러나게 된다는 문제가 있었는데, HTTPS가 이를 해결한 것으로 보입니다. 즉, HTTPS는 HTTP + TLS, SSL이고 HTTP의 확장된 버전으로 생각할 수 있습니다. 그리고 HTTP와 다르게 HTTP는 443번 포트를 사..
.http 파일 사용하기 리뷰어님의 추천으로 인텔리제이에서 Postman과 비슷한 기능을 수행 할 수 있다는 것을 알게 되었습니다. 바로 .http 파일을 사용하는 것인데요, 인텔리제이에서 디렉토리에 .http 파일을 만들면 다음과 같은 ui가 자동으로 구성됩니다. 그리고 application을 구동한 다음 위 초록색 실행버튼을 누르면 Postman처럼 요청이 갑니다. Response에 대해서도 아래 화면에서 확인이 가능합니다. 헤더나 바디까지도 지정해줄 수 있다는 점에서 좋은 것 같습니다. 또한 이 자체로 API 문서가 되는 셈이고, 버전 관리도 가능해서 유용하게 사용할 수 있을 것 같다는 생각이 드네요. 그리고 요청을 아래처럼 여러개 정의하는 것도 가능합니다. 그렇다면.. E2E 테스트를 굳이 코드레..
의존성 역전, 도메인 우선 개발 저는 아키텍쳐에 관심도 많고, 도메인 자체에도 관심이 많은 터라 이번 미션에서는 DIP를 적용해보고 싶다는 욕심이 들었습니다. 따라서 페어와 합의해 영속성 - 도메인 의존성을 역전시킨채로 미션을 진행했습니다. Repository의 인터페이스를 business layer에 먼저 만들어두고 domain, service를 구현 완료한 다음 Repository의 구현체 및 DB 테이블을 만들었습니다. 이 과정에서 무의식적으로라도 DB 테이블이나 쿼리문에 대해 신경쓰지 않게 되었습니다.(애초에 Repository 구현체를 만들지 않았으므로) 해당 접근방식을 통해 Layered architecture의 전통적인 문제점인 데이터 중심 설계로부터 벗어날 수 있었고, 순수 비즈니스 로직/..
레벨 2 첫 미션인 자동차 경주 미션이 끝났습니다. 스프링을 처음 접한 미션이었는데요, 이 과정을 통해 얻은 것들을 정리해보고자 합니다. 페어와 룰 정하기 + 아이스 브레이킹의 중요성 이번 미션의 페어는 체인저였는데요, 체인저의 제안으로 미션을 시작하기에 앞서 페어 프로그래밍 룰을 정했습니다. 스위치 시간이나 컨벤션, 그리고 구현 계획을 미리 정했는데요. 이 과정에서 체인저와 더 친해질 수 있었고 편한 마음으로 미션을 시작할 수 있었습니다. 게다가 이런 페어 프로그래밍 룰을 미리 정해 두었기에, 비교적 개발 피로도도 적었던 것 같아 좋았습니다. 스프링으로 하는 첫 미션이라 조급하고 막막한 마음이 있었는데, 확실히 규칙을 정하고 하니 안정적이라는 느낌을 받았습니다. 정말 좋은 방식인 것 같아, 앞으로 페어..
최근 Spring을 통해 개발을 진행하고 있는데요, Query Parameter, Path Variable 사용에 대한 저만의 기준이 잡혀 있지 않아 API를 설계하면서 대부분의 요청을 JSON으로 받았더라구요. 따라서 이번 아티클을 통해 Query Parameter, Path Variable은 무엇인지, 그리고 언제 사용할 수 있는지를 알아보면서 저만의 기준을 잡아가고자 합니다. query parameter란? 다음과 같은 주소가 있다고 해봅시다. /foo?name=teo&age=25 물음표 뒤를 보면 key=value 형식으로 이루어져 있는데요, 여기서 key-value 쌍 하나를 query parameter라고 합니다. 그리고 이런 query parameter가 여러 개 있는 경우 &기호를 통해 ..
문제 정의 장바구니 미션을 진행하면서 인증을 위해 Interceptor를 구성했는데요, Interceptor를 만들고 기존에 작성했던 컨트롤러 테스트들을 돌려보자, 제대로 동작하지 않는 것을 확인했습니다. 왜 이런 일이 발생하는 걸까 고민이 많이 되었습니다. 예외가 발생하는 지점은 ProductControllerTest였는데, 코드 상에서 예외가 발생할만한 부분은 존재하지 않았기 때문입니다. 코드는 아래와 같은데요, @WebMvcTest(ProductController.class) class ProductControllerTest { @Autowired private MockMvc mockMvc; @Autowired private ObjectMapper objectMapper; @MockBean priv..
Spring으로 웹 서비스를 구성하면 어느 URL로 클라이언트가 접근하던 간에, 공통적으로 작업을 수행시키고 싶은 경우가 존재합니다. 예를 들어 로깅이나 인증 절차 등이 있겠죠. 그리고 이런 작업을 컨트롤러의 핸들러 메소드 각각마다 배치하게 되면 중복이 발생될 수 밖에 없습니다. 하지만 이런 상황에 효과적으로 사용할 수 있는 장치가 하나 있는데요, 바로 Spring Interceptor입니다. Spring Interceptor는 요청을 가로채 특정 처리를 대신 해줍니다. 그리고 곧 알게 되겠지만, 중복 제거 이외에도 방화벽과 비슷한 기능을 제공해주기도 합니다. Spring Interceptor의 사용Spring Interceptor 클래스는 다음과 같은 두 가지 방법으로 만들 수 있습니다.HandlerI..
