일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 컨트리뷰팅
- circuitbreaker
- 운영체제
- bean-validator
- 마이크로서비스패턴
- resilience4j
- 객체비교
- DI
- Npoem
- GraphQL
- circular dependency
- IOC
- 쿼리셋합치기
- bulk_create
- SpringBoot
- 상속모델
- 프로젝트설정
- Java
- 좋은코드란
- 주니어개발자
- n poem
- Spring
- 일급함수
- Not Null constraint failed
- 2차원배열 정렬
- django
- cannot import name
- API문서화
- 함수형프로그래밍
- 토이프로젝트
- Today
- Total
목록Spring (7)
코딩 하는 가든
Spring Webflux에서는 엔드포인트를 매핑 하는 방식으로 기존에 사용하던 어노테이션 방식(@Controller, @RestController)이외에도 Router를 이용한 함수형 방식을 지원 합니다. 이번 글 에서는 웹플럭스에서 Functional Endpoints를 어떻게 사용하는지 알아봅니다. 당연한 이야기지만 우선 웹플럭스 의존성이 필요 합니다. dependencies { implementation 'org.springframework.boot:spring-boot-starter-webflux' } Functional Endpoint를 사용 하기 위해서는 함수형 인터페이스인 RouterFunction의 구현체를 만들어서 스프링 빈으로 등록 시켜야 합니다. import org.springfra..
이번 글에선 실제로 코드를 보며 어떻게 서킷브레이커를 구현 하는지 알아 보겠습니다. 예제에 사용된 코드는 여기에서 확인 가능 합니다. 우선 Resilience4j는 Spring MVC와 Spring Webflux 환경에서 모두 사용 가능 합니다. 이번 예제에서 Webflux를 선택 한 이유는 MSA환경에서 많은 api 호출이 일어나는 환경에서는 Webflux가 많이 유리 할 수 있고, 개인적으로 느끼기에 점점 Webflux를 이용하여 개발을 많이 해 가고 있다고 생각 하기 때문 입니다.-> 한창 뜨는듯 했으나 요즘은 다시 가라앉는것 같은 느낌이 들기도 ... (2024.06.05 수정) 물론 Webflux가 만능은 아니며 토비의 스프링의 저자이신 토비님 께서는 if kakao에서 MVC 환경 에서 문제 ..
Validation을 해보자 웹 개발을 하다 보면 서버에 들어온 요청이 서버에서 요구하는 스펙에 잘 맞게 들어왔는지 검사해야 할 필요가 있습니다. 예를 들어 회원가입을 할 때 이름은 필수로 들어와야 한다던지, 나이는 0보다 커야 한다던지 같은 것 입니다. 물론 이런 식으로 들어온 요청에 대해 검사를 할 수도 있을 것입니다. //이름이 비어있으면 exception을 던진다. if (request.getName() == null) { throw Exception; } // 나이가 0보다 작으면 exception을 던진다. if (request.getAge() < 0) { throw Exception; } 하지만 점점 커지는 웹 어플리케이션 에서 위처럼 요청에 대한 검사를 하다 보면 필드가 늘어남에 따라 코드..
블로그에서 사용한 소스코드는 https://github.com/97e57e/BLOG 에서 보실 수 있습니다. Filter 란? 사실 필터는 스프링의 독자적인 기능이 아닌 자바 서블릿에서 제공하는 기능입니다. 스프링 프레임워크에서 필터로 인증 등 다양한 작업을 하는 데 사용하니 스프링 프레임워크에서의 필터에 대해 기록 해 보고자 합니다. 아마 스프링 필터와 연관지어 검색을 하면 많이 보는 그림 중 하나 일 것입니다. 위 그림은 스프링 프레임워크에서 요청에 대한 라이프 사이클을 나타낸 그림입니다. 스프링 프레임워크는 들어온 요청이 DispatcherServlet에 의해 컨트롤러에 매핑됩니다. Filter는 요청이 DispatcherServlet에 의해 다뤄지기 전, 후에 동작합니다. 또한 Filter는 Fi..
의존성 주입을 받는 여러 가지 방법 스프링 프레임워크에서는 IoC 컨테이너를 통해 의존성 주입을 받는다는 것을 이전 글에서 알아보았습니다. 앞선 글에서는 컨테이너에서 꺼낸 배터리 빈을 Toy의 생성자로 넣어 주었습니다. 이는 의존성 주입의 한 종류라고 볼 수 있겠습니다. 스프링 프레임워크에서 의존성을 주입 받는 방법은 크게 3가지 정도가 있습니다. 1. 생성자를 통한 주입 2. Setter를 통한 주입 3. 필드를 통한 주입 각각의 방법에 차근차근 알아보겠습니다. 우선 세 방법에 대해 보기 전에 @Autowired 어노테이션에 대해 알아야 합니다. 이전 글에서 우리는 Battery Bean을 찾아 Toy 객체에 직접 넘겨주는 작업을 했습니다. 프로젝트에는 무수히 많은 Bean과 그들의 의존 관계가 있을 ..
이전 글에서 DI의 개념과 Spring에서의 DI가 어떻게 이루어지는지 살펴보았습니다. 대략 아래와 같은 구조로 이루어 진 객체들이 어떻게 의존성 주입이 일어나는지 코드를 통해 알아보겠습니다. 먼저 객체가 IoC컨테이너에 의해 관리되려면 스프링 Bean 등록을 해야 합니다. Bean으로 등록하는 방법은 xml 설정과 자바 코드로 등록하는 방법이 있는데 여기서는 자바 코드로 등록을 해보겠습니다. 다음과 같은 Battery 클래스가 있습니다. 이 Battery 클래스를 스프링 빈으로 등록해보겠습니다. (간단한 예시여서 따로 게터, 세터로 관리하지 않았습니다.) 스프링 Bean으로 등록을 하기 위해선 먼저 @Configuration 어노테이션을 가진 클래스를 하나 생성합니다. 그리고 @Bean 어노테이션을 가..
DI란? DI는 Dependency injection(의존성 주입)의 줄임 말로 어떤 객체가 다른 객체의 의존성을 제공 하는 것입니다. 어떤 장난감이 있고, 그 장난감이 작동 하기 위해서는 건전지가 필요하다고 가정 해 보겠습니다. 위의 상황을 소스 코드로 표현 하면 다음과 같을것 입니다 Toy toy = new Toy(); Battery batteryA = new Battery(); // 배터리 A를 주입 toy.setBattery(batteryA); 위처럼 Toy가 정상 작동 하기 위해서는 Battery가 필요합니다. 다시 생각해 보면 Toy는 Battery에 의존적임을 알 수 있습니다. 이 상황을 그림으로 나타내보면 다음과 같습니다. 하지만 이같은 상황에는 문제점이 있는데, A 건전지를 B 건전지로 ..