추가 기술들

Lombok

엄청나게 자주 사용했던 도구이다. 

 

Lombok이 없다면? 1 . 변수 생성 2. getter setter 생성. 3.메소드 생성

4. 로그 출력 구현을해준다 @ToString 5.builder로 바꿔달라.. 너무 많은 변경 필요 .

 

Lombok이란 , 동일한 코드를 ( 보일러 플레이트를) 다시 절대로 작성하지 않겟다. 

즉, 생산성 도구라고 볼 수 있따. 

이미 builder로 구현이 되어있고, eqaul도 되고, tostring도 다 되어버리네?

-> lombok이 해준다

 

접근자 설정을 내가 해주지 않아도 된다 . 

spring initalizer로 간단하게 사용할수있따. 

 

인기 기능

1. @Data

getter+setter+requiredargsconstructor(생성자 중에 필수필드(final 키워드가 있다면, 생성자로만 받을 수 있다)

를 인자로 받는 생성자<따로 생성자 설정 필요x>)+tostring+eqaulsandhashcode

-> 근데 사용을 주의해야됨. 너무 편하기 때문이야 .  <모르거나 원하지 않는 기능>

 

2.@Value

불변 객체 <setter는 당연히x > +requiredconstructor는 있음. 

모든 access level을 private final로 설정

 

Lombok의 문제는, 동작의 행동이 예측되지 않는다. 

ex) 매개변수 4개중 name만 final (field final은, 필드 선언시, 혹은 생성자에서 초기값을 지정)

왜 final로 되어있지 name이? 처음에 초기값을 넣고 싶다는 뜻이겠네 .. 

builder.build로 name을 설정 안해서 남이 생성해버리면 어떡하지 

-> 협업에서 모든것을 소통하지 않기 때문에, 문제가 발생할 수 있다. (잠재적에러)

 

서로가 서로를 참조하는 형태는 -> 순환참조라는 문제가 발생한다. 

(예전에 같이 했던 프로젝트에서, 순환참조 문제가 있었음을 기억하자 )

Lombok은 exclude라는 attribute를 tostring에 적는다. 순환 참조되는 필드를 문자열로만 표현

  

Lombok tip ! 

springboot 2.4.4 미만시 자바 16과의 호환성 문제가 있었다. 

 

 

Spring Configuration Processor

 

properties의 추천 받을 수 있는 자동완성, 값의 예측 등을 강하게 도와준다. 

 

Spring Cache Abstraction 

애플리케이션에 투명하게 캐시를 넣어주는 기능. 투명하다가 뭐야 ?

Clinet Server모두 cache의 존재를 모른다.  (cache란 자주 사용되는 데이터나 값을 복사해놓고, 저장공간이 작은 대신 빠르게 동작한다. 반복작업 등에서 성능을 많이 향상시킨다 )

 

실제 적용 -> @Cocheable("입력 인자의 이름") -> unique한 key로 생성할 수 있다. 

즉, 같은 동작을 반복할때 메모리에 저장하고 있다. 캐시가 결과를 반환해주는 방식이다.

 

enablecaching -> cacheable-> cache evict -> cacheput의 사용 

적용을 하고 싶은 곳의 repository의 method에 @cocacheable("입력 인자의 이름") , @Enablecaching

주의 사항 -> 모든 bean이 등록된 후에야 적용 (@postconstruct의 정의는 의존성이 완성된 뒤 )

정의의 문제 때문에 적용되지 않을 수 있다. (실제 오류 떄문에 당황했던 부분)

-> 이 경우에는 evenlistner(applicationreadyeven.class)로 변경해야한다. 

이러한 모든 코드를 알 수는 없지만, 오류가 발생하면 정의를 확인하고 유사한 어노테이션을 사용하는 것이

현명하다. 

 

Redis? 

 실무에서 자주 사용하는 캐시 서버 .

 properties 에서 직접 넣을때는 radis 의존성을 넣어줘야 한다. 

Cache전용 config class를 하나 생성해주어서 설정하는 방식을 추천한다.

<허나, redis를 아직까지 프로젝트에서 사용해볼 경험은 없다. 차후에 다시 학습하자.>

 

보안을 위한 암호 관리 . 

DB에 접근하기 위한 암호를 어디에 저장해야할까? 

오픈소스 도구 Vault를 사용한다. 

Vault 서버를 띄워놓고, 그 곳에 민감 정보를 관리한다. 

인증과 권한 check 또한 제공한다. + 데이터 암호화 또한 지웧난다

장점 : 민감 정보가 분리되고, 보안성이 강화된다. 

단점 : 설계에 따라서, Vault 서버 오류시 서비스 문제가 발생할 수도 있다.

 

설정시- > dependences + management 추가 + ext 추가 

8200번 port가 기본이다. 이곳에서 token을 가지고 온다. 

그곳의 secret에 , 저장할 수 있다. 

Spring cloud vault는, Spring property에 저장한다. 그러므로, 만약에 properties에 

spring.datasource.username = 으로 사용할수 있다. 

spring 실행시 최초 1번 실행 -> 서로 handshake처럼 주고받는다. 

그 이후 vault 서버에서 한번에(!) 다가지고 온다. 

 

가져온 이후 field로 사용할떄는 @Value("${spring,datasource.username}") 와 같이 value를

properties에서 가져와서 사용한다. 

 

이때 경로는 secret /프로젝트명/test->기본 pacakge -> application+test -> test를 

scan 해서 가져온다. 

이와 같은 방식을 사용하면, 코드를 배포하거나 공유할때, 민감정보가 코드에 포함되지 않게 할 수 있다.