데이터 통신의 기본 개요
Br에서 BE로 API를 요청할 때 부하를 분산하기 위해 LB(부하 분산기)를 통해 이용자가 제일 적게 scale-out된 BE서버에 요청하고 BE 에서는 샤딩을 통해 데이터를 분산 저장하는 DB에 데이터 등록 혹은 요청을 하는데 이때 요청한 API(데이터)에 따라 샤딩으로 나누어진 테이블을 가진 DB로 요청을 한다.
refreshToken
Br에서 로그인 요청을 BE로 하는 경우 BE 에서 리턴값으로 accessToken 뿐 아니라 refreshToken을 같이 Br에 넘겨준다.
Br에서는 accessToken을 state에 저장하고 refreshToken은 보안설정(httpOnly, secure … )이 완료된 쿠키에 담아준다.
Br에서 토큰이 필요한 작업을 하는 경우 토큰 만료시 API에서는 에러(Unauthenticated)를 리턴한다
만료 에러를 받은 Br은 _app 에서 기존에 설정한 에러 발생시 처리 프로세스에 따라 처리를 하고 로그인(토큰) 관련 에러라면
- 에러 발생시 실행
- 인가에러인지 체크
- refreshToken으로 accessToken 재발급 요청
- 새로 받은 accessToken을 state에 저장
- state에 저장된 신규 토큰으로 실패했던 API를 재요청 (API요청에 필요한 인자값은 기존의 것을 사용하되 토큰만 바꿔 요청)
이런 식으로 프로세스를 진행시킨다.
MSA
서버를 API에 따라 게시판, 결제 등으로 나누어 Br의 요청에 따라 API가 향하는 서버를 다르게끔 세부적으로 나눈 것을 말함.
세부적으로 나뉘는 만큼 팀별로 하나의 서버를 맡아 세밀하게 설정을 해줄수도 있고 관리(유지보수)의 효율성이 증가한다.
하나의 서비스가 에러로인해 중단되어도 다른 서비스는 살아있기 때문에 사이트 이용에는 크게 문제가 없다.
Graphql이 사실은 rest-API ?
게시글 조회 : axios.get(API address | endpoint)
게시글 등록 : axios.post (API address, {data} )
기존 방식은 이런식으로 조회와 등록이 나뉘고 하나의 데이터에 하나의 요청을 보내야하는 문제 (underFetching)이 있었다.
GQL은 endpoint가 하나인 rest-API이다.
API요청시 어찌됐든 데이터를 보내야 하기 때문에 항상 POST방식으로 동작
서로 다른 API 요청을 개별적으로 요청할 필요 없이 하나의 요청에서 여러 API를 요청해서 여러 데이터를 받아올 수 있다. (underFetching 문제 해결)
GQL로 데이터를 요청할 때 요청 자체는 post 로 보내기 때문에 post에 대한 응답은 항상 ‘200’ 으로 온다.
쿼리 실패는 post 로 요청한 내부의 쿼리에서 문제가 발생한 경우이다.
