돌맹이의 개발블로그

2장에서는 나의 경우 인증인가에 대해 어떠한 문제가 발생하고 있는지 소개 해보려고한다. 그전에 나의 개발 구축 기반부터 설명하려고 한다 1. Spring Cloud 기반 Spring cloud와 Netflix Eureka 등을 기반으로 한 microservice를 구축 하고 있다. 그리고 기존의 Monolithic방식으로 작성된 프로젝트를 MSA 기반으로 옮기는 작업을 진행중이다. 여기서 알아야 할 점은, Spring Cloud Api-gateway의 경우에는 비동기 방식 즉, Spring.io에서 밀고있는 Spring Webflux 방식이이라는 것이다. 이것이 왜 문제가 될까? 2. Spring.io에서 밀고 있는 2-Track 스프링에서는 2-Track으로 개발을 하고 있다. Reactive Stac..

단일 서비스가 아닌 마이크로서비스에서의 인증과 인가의 문제는 상당히 까다롭다. 특정서비스에서 인증인가의 정보를 다른 서비스에도 공유하여야 한다는 것이다. Spring Security를 사용한다면, 크게 Session과 token으로 인증인가를 처리한다. 1. Session 세션의 경우에는 세션의 공유를 할 외부 스토리지를 두고 공유하는 시스템을 구축하여 해결 할 수 있다. 이것을 Session Clustering 이라고도 한다. 내 의견을 말하자면, 성능적으로는 좋지 않다. 외부 스토리지가 필요하다. 통신의 횟수로만 봐도 무척이나 많아지게 되고, 또한 각각의 독립된 server instance에서 인증인가에 관련된 중복 코드의 양이 무척이나 많아지게 된다. 2. Access Token Client가 서버..

개요 항상 @RequestParam를 사용할때마다 애매한 느낌을 받았다. 어떤 지점에서 애매함을 느꼈을까? v1 param데이터로 스트링을 받기로 했다. param이므로 getmapping이 가능하다. 단일의 값이 아닌 list로 받기로 하였다. 1)body의 form-data로 받기 결과값은 당연히 된다. 지켜볼만한 지점은 value값을 어떠한 {}나 []로 감싸지 않아도 된다는 것이다. 2) Params로 받기 uri에 쿼리파라미터를 입력하는 params의 형태도 가능하다. 3) 동시에 body form-data와 params로 받기가 될까? 된다..! 웃긴점은 params 데이터보다 바디값이 먼저 들어온다는것이다. 2가지를 혼용해서 써도 되고, param데이터를 body form-data로 보내도 ..

도입 (1)편에서 말했듯이 나는 Query Mapping을 JPA Querydsl을 주로 사용한다. SQL이 중요한것은 잘 알고 있지만, 여건상 많이 공부를 하지 못한것은 사실이다. 마음같아서는 QueryDsl만 계속 쓰고 싶지만.. 언젠가, Native SQL을 사용해야만 하는 경우가 생길 것이고, 이를 위해서 미리 준비를 해두려고 한다. 본론 Native SQL을 사용하기 위한 기본엔티티 Post 이외에 Controller 와 Repository로 구성된 2개의 클래스 예시에서 시작해 점점 확장해 나가는 방식으로 글을 작성 할 예정이다. V1 개요 Data jpa에서 제공하는 기능인 @Query를 이용하여 native query 작성 Controller @RequiredArgsConstructor @..