해당 경고는 Spring Data Jpa 에서 'PageImpl' 인스턴스를 JSON으로 직렬화 하려고 할 때 발생한다. 경고의 전문은 아래와같다.Serializing PageImpl instances as-is is not supported, meaning that there is no guarantee about the stability of the resulting JSON structure! For a stable JSON structure, please use Spring Data's PagedModel or Spring HATEOAS and Spring Data's PagedResourcesAssembler. 즉, JSON으로의 변화가 안정적으로 이루어지지 않을 수 있다는 것이다. 해당 경고를..
스프링부트
테스트 가능성이라는 단어를 들어봤나요? 영어 단어로 Testability라고 합니다.테스트하기 쉬울수록 Testability가 높습니다. 더 나아가 테스트하기 쉬운 코드일수록 좋은 설계일 확률이 높습니다. 하지만 저를 포함한 많은 사람들이 테스트를 어려워하고 있습니다. 테스트를 어렵게 만드는 요소는 무엇일까요? 테스트를 어렵게 만드는 요소테스트를 어렵게 만드는 요소의 결론부터 말하자면 테스트하려는 대상의 입력과 출력에 있습니다. 테스트는 테스트하려는 대상의 입력을 쉽게 변경할 수 있고, 출력을 쉽게 검증할 수 있어야 작성하기 쉽습니다.하지만 숨겨진 입력이 존재하거나 숨겨진 출력이 존재한다면 테스트를 검증하기 어려워집니다. 그렇다면 숨겨진 입력과 숨겨진 출력이 대체 무엇일까요? 한번 알아봅시다.숨겨진 입력..
테스트 대역이란 무엇일까요? 네트워크에서 사용하는 대역(bandwith)과 비슷합니다만. 전혀 관련이 없답니다!테스트에서의 대역은 오롯이 테스트를 위해 만들어진 가짜 객체 또는 컴포넌트를 의미합니다. 아래의 상황에서 테스트코드를 짜본 적이 없는 개발자라면 공감하실 수도 있겠습니다. 회원가입을 완료하면 회원 테이블에 저장하고 환영 이메일을 보냅니다. 이런 상황에서 테스트코드를 짜야한다면 머리가 지끈지끈하지 않으신가요? 그리고 이런 고민도 할 수 있겠습니다."테스트를 할때마다 디비에 계속 저장되겠는데..?" , "더미 이메일을 계속 보내야 하나..?" 이 고민을 해봤다면 계속 글을 읽어도 좋을 거 같습니다. 저와 함께 가보시죠.아까의 상황을 다시 가져와 보겠습니다.회원가입을 완료하면 회원 테이블에 저장하고 ..
현재 프로젝트에서는 GPT와의 통신이 필수인만큼 외부 API를 꼭 사용해야 한다. 그렇기에 이전에도 잘 써왔던 RestTemplate를 적용해서 프로젝트를 진행하고 있었다.전혀 아무 문제 없이 외부 API를 호출했고 원하는 대로 기능완성도 되었다. 평범한 일상을 보내던 중 자극적인 문장 하나를 보게 되었는데..."RestTemplate은 곧 deprecated 된다" 이걸 보자마자 머리가 띵했다. (나 잘 쓰고 있는데 왜?) 그렇게 급한 마음에 좀 찾아보니 현재 WebClient라는 기술이 잘 사용되고 있고 RestTemplate은 유지보수 단계에 들어갔다고 한다.나도 최신기술을 도입해보고자 하는 마음에 WebClient 기술을 간단하게나마 공부해 봤다.Webclient는 Spring5.0에서 WebFl..
똑같은 데이터를 매번 데이터베이스에서부터 가져오면 사용자와 서버입장에서 모두 비효율적이다. 그렇기에 한번 가져온 데이터의 경우엔 캐싱처리를 해서 두 번째 요청부턴 효율적으로 가져오고자 한다. 현재 프로젝트의 경우에 RefreshToken과 로그아웃 관리를 위해 Redis를 사용하고 있다. 그렇기에 캐싱 저장소로 Redis를 사용해 보기로 했다. ❗️❗️ 주의 ❗️❗️과정상의 코드는 별로 없다.바로 캐싱을 적용하기 전에 간단하게 공부를 해보니 캐싱에도 여러가지 전략이 있다고 한다. 캐싱 전략을 세울 때 유의해야 할 것은 무엇일까?캐싱 데이터는 주로 메모리에 저장되기 때문에 용량 제한이 있다. (주로 16 ~ 32 기가)따라서 캐싱 데이터의 유효기간 설정이 중요하다.따라서 어떤 데이터를 캐싱해 둘지 선택하는..
오랜만에 읽으면서 계속 감탄을 하게 되는 책을 접하게 되었습니다. 자바 / 스프링을 공부하고있는 여러 사람들이 있을 것입니다. 아래는 제가 이 책을 접하기 전에 처했던 상황인데요 이에 공감하는 사람들이 꽤 있지 않을까 싶습니다.객체지향이 중요한건 알겠는데... 스프링에는 어떻게 적용해야 하지?SOLID, 테스트, VO, DTO... 등 여러 단어는 접해봤는데 누군가 질문했을 때 떳떳하게 답 할 수 있나?계층형 구조와 헥사고날 구조? 어떤게 더 좋은거지?테스트가 중요한 건 알겠어 알겠는데 개발하면서 와닿지는 않네.. 이렇게 보니 제가 과연 자바 / 스프링 개발자라고 불려도 되는가 싶네요. 그냥 스프링부트를 쓸 줄 아는 사람 그 이상 그 이하도 아닌 거 같습니다. 하지만 이 책을 읽고나니 위의 질문에대해 자..
Springboot 3.x 버전에서는 뭔가 많이 바꼈다. 이번 프로젝트를 진행해보며 CORS 문제를 해결을 어떻게 했는지 써보겠다! 프론트에서 우회하는 방식도 있지만 스프링부트에서 해결하는 방식으로 진행했다. 일단 나는 Spring Security를 사용중에 있으므로 Security를 사용했을때를 기준으로 설명하겠다. public class SecurityConfig { ... CorsConfigurationSource corsConfigurationSource() { return request -> { CorsConfiguration config = new CorsConfiguration(); config.setAllowedHeaders(Collections.singletonList("*")); con..
JWT와 Redis를 이용한 클라이언트의 로그아웃 로직을 구현하던 도중 발생한 트러블이다. 간단하게 클라이언트가 로그아웃 요청을 보낼 경우 해당 클라이언트의 Header에서 AccessToken을 받아와 토큰을 이용해 RefreshToken을 블랙리스트에 등록하는 로직이다. 로그아웃 로직이 완성됐다고 생각하고 포스트맨으로 실행시켰을때 위의 사진에서 볼 수 있듯 500 서버에러가 발생하였다. 왜 이런 이유가 발생할까? 에러 로그를 슥 살펴보던 도중 "Member가 UserDetails로 cast 될 수 없다"는 로그를 발견함과 동시에 "loadByUser"쪽에서 문제가 발생한걸 확인해 볼 수 있었다. 이게 그 문제의 loadByUsername 메서드이다. 코드를 쓱 봤을때는 마지막에 (UserDetails..
