- 아래 내용은 https://docs.spring.io/spring-framework/reference/web/webflux/new-framework.html 의 내용을 정리한 것입니다. (번역한 것도 조금 있음)
## SpringWebFlux가 만들어진 이유
- 적은 수의 스레드로 동시성을 처리하고, 더 적은 하드웨어 리소스로 구동할 non-blocking 웹 스택이 필요하였다. 서블릿을 사용한 방법은 이것을 충족히켜주지 못했다.
- non-blocking 을 구현하기위해서는 언어적 지원도 필요한데 jdk 8 부터 functional 프로그래밍이 가능해졌다. (자바스크립트에서의 화살표 함수를 생각해보자)
## "Reactive" 란
- 보통 반응형이라고 하면 브라우저 사이즈가 변하거나, 마우스 클릭을 했을때 이벤트를 발생하는 것을 말하지만, I/O 이벤트에 반응하는 네트워크도 반응한다고도 할 수 있다.
- 따라서, 네트워크에서의 "반응적"이란 요소는 non-blocking과 관련이 깊다. nodejs가 폭발적인 성장을 한 이유가 이것일 것이다.
- non-blocking 이 잘 이해가 안된다면 "event-loop"를 공부하자
## Spring WebFlux가 선택한 라이브러리
- "Reactor"를 사용하고 있다.
- project reactor : https://projectreactor.io/
- webflux를 공부하려면 reactor 공식 문서를 보자
## 서버
- Spring WebFlux는 Tomcat, Jetty, Netty, Undertow에서 사용할 수 있다.
- Tomcat, Jetty는 MVC와 WebFlux를 모두 사용할 수 있지만 사용법이 매우 다르다.
- Undertow는 ServletAPI 없이 Undertow API를 직접 사용한다.
## 성능
- 성과에는 많은 특징과 의미가 있습니다. [반응형 및 비차단 방식은 일반적으로 애플리케이션 실행 속도를 더 빠르게 만들지 않습니다]. 어떤 경우에는 가능합니다. 예를 들어 `WebClient`원격 호출을 병렬로 실행하기 위해 사용하는 경우입니다. 그러나 [비차단 방식으로 작업을 수행하려면 더 많은 작업이 필요하며 이로 인해 필요한 처리 시간이 약간 늘어날 수 있습니다.]
- [반응형 및 비차단형의 주요 예상 이점은 작고 고정된 수의 스레드와 더 적은 메모리로 확장할 수 있는 기능입니다. ]이는 애플리케이션이 더 예측 가능한 방식으로 확장되기 때문에 로드 시 애플리케이션의 탄력성을 높여줍니다. 그러나 이러한 이점을 관찰하려면 약간의 대기 시간(느리고 예측할 수 없는 네트워크 I/O 혼합 포함)이 필요합니다. 이것이 바로 반응성 스택이 강점을 보이기 시작하는 지점이며, 그 차이는 극적일 수 있습니다.
## WebFlux 정말 써야 할까
- 외부 api호출을 위한 webclient를 사용하는 것 이상으로하는 것은 의미가 없다.
- statck 자체가 다르므로 또다른 프레임워크를 익히는 것과 다를바 없다.
- jdk21 에 virtual thread가 지원되기 시작했다. 비교문서에서는 가상스레드가 성능이 더 좋다는 결과가 많다.
- reactive stack을 아는 개발자를 구할 수 없다.
- 공식문서에도 적혀있지만 reactive를 사용한다고 해서 속도가 더 빨라지지 않는다. 적은 리소스를 조금 더 활용할 수 있는 정도이다.
- reactive는 nodejs를 시키자.
Session 대신 JWT를 사용하는 이유 실 서버는 하나의 인스턴트로만 동작하지 않는다. 서버의 고가용성(high availabliity, HA)을 확보하기 위해 두 개 이상의 병렬서버로 운영하게 된다. 서버가 병렬로 운영되는 상황에서 세션을 사용하면 각 서버간의 세션을 동기화하는 문제가 발생한다. 이를 해결하기 위해 공유 데이터베이스를 이용한 세션공유 기법들을 사용하기도 한다. 서버가 많아지면 세션동기는 더 어렵다. JWT를 사용하면 세션사용으로 인한 서버 자체에 부담도 줄이면서 공유 세션에 대한 관리가 한층 수월하다. 스프링 시큐리티 - SecurityConfig.java session을 사용하지 않도록 설정 jwtAuthFilter 추가 httpBasic 제거 - JwtAuthenticationFilter.java config.filter 패키지에 파일 추가 jwt dependency 추가 (3개). gradle refresh하는 거 까먹지 말기 config.service 패키지에 [JwtService.java](http://JwtService.java) 추가 jwtService와 UserDetailService final field 추가. @RequiredArgsConstructor 까먹지 말기 - config.service.JwtService 소스 참조해서 파일 작성 - controller, service 수정 User 를 리턴하면 pwd가 그대로 노출되므로 AuthResponse와 AuthRequest로 교체 Github https://github.com/ohhoonim/factory.git 유튜브 영상 스프링부트 - 보안 JWT JWT - refresh 토큰과 logout
Inlay Hint > Parameter names java.inlayHints.parameterNames.enabled: literals java.inlayHints.parameterTypes.enabled java.inlayHints.variableTypes.enabled editor.inlayHints.enabled: offUnlessPressed Code lens editor.codeLens: true editor.codeLensFontSize java.referencesCodeLens.enabled java.implementationCodeLens: all ligature 폰트 설정 editor.fontFamily: 'D2Coding ligature’ "editor.fontLigatures": true, 편집기 확대 축소 단축키 설정 zoom 으로 검색 Google Style Formatter 설정 java.format.settings.url https://raw.githubusercontent.com/google/styleguide/gh-pages/eclipse-java-google-style.xml JDK 설정 java.configuration.detectJdksAtStart Language Server JAVA_HOME 설정 java.jdt.ls.java.home Gradle JAVA_HOME 설정 java.import.gradle.java.home Installed JDK 설정 java.configuration.runtimes Static 클래스, 메서드 import java.completion.favoriteStaticMembers "org.springframework.test.web.client.match.MockRestRequestMatchers. ", "...
# 5-Step Architecture Spec 이 문서는 헥사고날 아키텍처를 실무적으로 변형하고, DDD의 전략적 설계를 극대화한 5-Step Architecture의 표준 공정을 정의한다. 샘플 리파지토리 : https://github.com/ohhoonim/smart-factory/tree/main/back/factory-api-module ### Core Philosophy > "Service는 배달부(Messenger)일 뿐, 뇌(Brain)는 **Model**에, 법(Law)은 **Policy**에 둔다." > --- ## The 5-Step Standard Process ### Step 1: 도메인 자아 확립 (Domain Model Discovery) 비즈니스의 핵심 상태와 행위를 관리하는 Aggregate Root(AR)를 정의한다. - **원칙**: 데이터 필드가 아닌 '상태 변화의 규칙'과 '생애주기'에 집중한다. - **핵심**: AR 내부에서만 상태 변경이 가능하도록 캡슐화하며, 외부로부터의 직접적인 필드 수정을 금지한다. ### Step 2: 법전 정의 (Policy Abstraction) 비즈니스 제약 조건 중 변하기 쉬운 규칙(보안, 한도, 계산 로직)을 인터페이스로 추상화한다. - **원칙**: 도메인 모델이 프레임워크(Spring)나 환경 설정에 오염되지 않도록 보호한다. - **효과**: 정책의 변경이 모델이나 서비스의 코드 수정을 유발하지 않도록 결합도를 낮춘다. ### Step 3: 도구 제작 (Activity Implementation) 도메인이 외부 세계와 소통하기 위한 구체적인 기술(DB, Storage, 외부 API)을 구현한다. - **원칙**: 헥사고날의 **Output Adapter** 역할을 수행하며, 기술적 복잡성을 이 계층에 가둔다. - **명칭**: `QueryActivity`(조회), `CommandActivity`(...
댓글
댓글 쓰기