MSA Shopping Mall

일단 Hot-item-collector 를 리팩토링한다고 하긴 했는데사실 아예 새로운 서비스가 될 수도 있으며 말그대로 리팩토링하는 과정이 담길 수 있다.그리고 서비스 런칭 수준으로 프로젝트를 끌어올렸을 때 기준을 잡는다면 소요 기간은 아마 30-50일 사이로 잡히지

저번 포스팅에 이어 2번째 포스팅은 API 명세 부분이다.일단 MVP의 목표로 다음과 같이 선정했었는데User Service → 회원가입 & 로그인 (JWT)Product Service → 상품 목록 조회Cart Service → 장바구니 추가Order Service

일단 이번 포스팅에서 API Gateway와 그 외의 기술 스택을 제대로 선정하고 진행할 계획이다.확정된 기술은 다음과 같으며MSA 기반이므로 각 서비스의 기술 스택 확정Spring Boot → User/Auth, Product, Order, Cart 서비스MySQL

이번 프로젝트는 Poly Repo부터 시작해볼 생각이다. 일단 Mono Repo와 Poly Repo의 차이를 간략하게 알아보자 Mono Repo vs Poly(Multi) Repo Mono Repo : msa-shopping-mvp 하나로 통합 즉 우리가 그냥 G

이번 포스팅에서는 User와 Auth 부분을 구현할 예정이다. User 그렇지만 User는 매우 간단하다. 지난 포스팅에서 얘기 했듯이 회원을 등록하는게 User-Service가 하는 일이다. 다만 1가지 추가가 되었는데 Auth에서 해당 User를 찾을 수 있도

Feign Client는 HTTP 클라이언트를 구현한 인터페이스라서 HTTP 요청의 특성을 그대로 따르게된다

이번 포스팅은 API Gateway 부분을 구현할 차례다. 지난 포스팅에서 User와 Auth간의 소통을 구현했었는데 별개의 서버에서 API를 불러다 사용하는 방식으로 구현했었다. 그렇지만 MSA는 서버간의 직접 소통을 권하지는 않는다. 이 문제를 해결하기 위해서

일단 지난 포스팅에서 얘기하지 않았던 Mono와 Flux를 알아볼 겸? 사실상 Spring WebFlux를 알아야 이해가 가능하기 때문에 Spring WebFlux를 공부하도록 하겠다. Spring WebFlux Spring WebFlux에 대해 조금 더 알고 가야

이번 포스팅에서 진행할 내용은 X-User-Id의 보안적 취약점을 해결하기 위한 포스팅이다. 6번 포스팅의 하단부분에 다음과 같이 적어뒀었다. > 보안적인 주의점 일단 X-User-Id 헤더와 같은 경우 Client에서의 직접적인 입력을 반드시 막아야 한다. > >

MicroService의 경우 트러블슈팅을 먼저 진행하고 가야 할 것 같다. 그렇지만 따로 문제가 생겼던 코드는 커밋을 해두지 않았기에 실행했던 스크린샷과 같은 자료가 없고, 그냥 이러한 문제를 겪었었다 정도를 적는 시간이 될 것 같다. 트러블 슈팅 내가 겪었던

이제 드디어 메시지큐를 이용한 작업을 시작할 예정이다.

계속 구현하면서 느낀건데..Postman의 한계인건지, 내 코드가 너무 조잡한건지그것도 아니라면 내가 아직 MSA에서의 인증 방식에 대해 제대로 깨닫지 못한건지..굳이 JWT를 통해서 CustomHeader를 생성하고 Downstream까지 해놓고 매 요청마다 JWT를

지난 끄적임에서 왜 이렇게 안되는지에 대해 적었는데(물론 포스트맨에서 사용해서 그런 걸 수 있긴 하지만)일단 얘기해보자면 코드 자체는 그렇게 크게 문제가 없었다.다만 Gateway든 다른 서비스에서든 생성한 커스텀 헤더를 클라이언트쪽에서 확인할 수 없는 문제였다.즉,