회원정보 조회용 API 요청

[changhwa]

회원정보 조회용 API를 요청합니다.
우선 MockService로 개발할거니 차후 1사이클이나 이후도 괜찮습니다.^^

사용처는 스터디 그룹맴버의 정보를 보기 위해서 인데요.
굳이 User랑 직접관계없이 이런정도의 API 를 제공해주시면 감사하겠습니다.
(또는 의견 주세요)

# 예를 들면..^^
List<User> getUsersInfo(List<String> userIds)
User getUserInfo(String userId)

# 또다른 예
/api/user/{id}/info
/api/users/{ids}/info

[scarfunk]

User 테이블와 UserInfo(Detail?) 테이블를 따로 가져가야 할지 모르겠군요..
스키마 설계? 도 필요하겠네욤..혹시 잘아시는분들은 아이디어 부탁드려용 :)

[changhwa]

한가지 위의 이슈를 조금 의아해 하실 수 있는데요.
왜 그냥 조인하면되지 User 정보를 따로 요청하는가 입니다.

User 는 사실 common에 들어올 수 있어서 제가 처음 생각한 구조에 대한 설명엔 조금 부적합합니다만..

제가 꿈꾸는 구조중 하나는 일명 MSA 인데 Micro Service Architecture 입니다.
완벽한 MSA를 구현하기 위해서는 일명 API Gateway 가 필요하고
그에 따라 Message Queue 등 여러 보조 도움이 필요하기 때문에 먼 훗날 과제로 생각하고있습니다.

또한 전 MSA가 갖고 있는 구조적 장점 중 하나는 서로 서비스가 직접적 연관관계를 갖고 있지 않아
서로 다른 서버에 돌려도 아무런 문제 없이 동작한다는 점에 주목 했습니다.

즉 직접 패키지를 호출 하는 연관관계를 최소화하면
개발시 저는 제 개발 패키지에만 집중하면 되고 빌드시간에도 상당한 이점을 확보 할 수 있습니다.
책임 소재도 분명해지구요.

다만 지금 이렇게 하기엔 너무 많은 개념이 도입되어야하고 서로 벅찰 수 도 있기에
현재는 기능구현 에만 초점을 맞추고 차후 이런 부분을 도입해 나갈겁니다.

그러기 위해서는 공통분모를 제외하고 가능한 직접호출 (의존성) 을 없애야 하므로
평소에도 신경을 쓰시면 차후에 서로 피차 편하지 않을까 합니다.

더불어 저는 평소에도 User 테이블과 왜 조인을 해야하는가라는 명제를 항상 고민해왔습니다.
실제로 User 정보를 보는것은 User아이디를 클릭했을 경우지
그 전에는 흔히 갖고있는 아이디, 닉네임 정보만 보게 됩니다.

물론 JPA에서 제공해주는 Lazy 로 하면 된다고는 하나 그것보단 애초에 연관을 끊고
저는 조회 가능한 키만 하나 들고 있으면 언제든지 호출이 가능하므로
이게 여러모로 비용적으론 아낄 수 있다는 생각을 하였습니다.

단점은 User 정보 변경시 다른테이블에 있는 정보는 어떻게 할 것인가 라는 이슈가 발생하는데
이건 기획적으로 풀어갈 수도 있고 ( 닉네임등은 작성시기를 기준으로 한다 -네이버카페-)
또는 User 변경 에 대해 훅 을 제공할 수 도있습니다. (이건 사용할 사람만 써라 뜻)

궁금하신건 다시 의견주세요