일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- ㅉ때
- nGinder
- 월급루팡 일지
- Armeria
- OIDC
- Ingress Controller Fake
- 핀포인트
- pinpoint 2.5.3
- pinpoint
- 논블록킹 성능
- hbase 저장공간 설정
- formik
- 오블완
- save/update
- jsonMarshaller
- reids
- LPOS
- intellij
- 티스토리챌린지
- Loki 로그
- fake jwt
- 노드간 통신
- 더티체킹
- 플루터
- RedirectService
- 애자일 싫타
- 개발 어렵당.ㅠ
- jar 배포
- R2DBC Paging
- UnsupportedOperationException
- Today
- Total
대머리개발자
API 호출 vs DB View 본문
사용자를 관리하는 모듈(서버)이 별도로 존재하기 때문에
사용자 정보가 현재 동떨어져 있다. (독립적이다. -> 나름 MSA )
접근하기 위한 방법은 기본적으로 API를 이용하면 된다.
그러나 하나의 정보가 아닌 목록에 표현되는 정보라면 API호출은 성능 문제를 야기할 수 있다.
(목록 Row 만큼 호출하는 것은 초딩이 봐도 아닌것을 금방 눈치 챌 수 있다.)
두가지 방법이 있는듯 한다.
1. DB View 제공해 Join해서 처리
2. 해당 CASE의 경우 노출되는 정보를 같이 저장한다.
3. 목록(리스트)에서 필요한 정보를 한 번의 API로 처리
각각의 장 단점이 있다.
-> 현재 게시판 모듈에서 2번으로 처리하고 있다.
게시판의 목록에서 닉네임을 보여주고 있는데 해당 정보를 게시판에 등록할 때 같이 저장한다.
별도 저장한 이후 닉네임에 대한 동기화가 없다고 했기 때문에 진행한 부분이다..
추후 닉네임이 변경되도.. 게시판에는 이전의 닉네임으로 보이는것이다. ㅎ
-> 추가 개발하고 있는 쿠폰 모듈에서도 사용자 정보인 이메일을 목록화하는데 필요해서 고민이 시작했다.
이 또한 동일하게 등록할 때 API 호출해서 같이 저장해 버리면 되는데.... 기존 등록된 데이터를 마이그레이션 해야 한다..
해서 1번 혹은 3번의 방안을.. 같이 고민.
1번의 강한 의존이 걸리는 반면 단순해 진다.
3번의 느슨한 결합이기 때문에 유연한과 확장성이 조으다..
역시나 정답이 없는 것에 대한 고민은 너무 어렵다. ㅎ
내게 맞는 의존은..... 기획적으로 이메일이 굳이 필요하냐? ㅋㅋ 기획자와 파이팅!!ㅋ
'개발이야기 > 개념' 카테고리의 다른 글
1년이 더해지는 날짜 Formatter 이슈 (0) | 2025.01.03 |
---|---|
flatMap vs map (1) | 2024.11.20 |
비트 연산은 생각보다 파워풀한 친구다. (0) | 2024.08.19 |
static 익숙하게 그냥 무지성으로 사용하면 큰코.. (0) | 2024.07.26 |
애플 oauth (1) | 2024.07.18 |