Br에서 로그인을 해서 토큰을 받아오는 과정 인증(login)
Br에서 accessToken을 넣어서 api요청 보내면 DB에서 accessToken 검증하고 다시 DB에서 api 요청 처리하는것 인가
scale out : backEnd 컴퓨터를 복사해서 여러대 놓는것, backEnd의 컴퓨터가 stateful 이 아닌 stateless 상태여서 가능(데이터 베이스로 로그인 데이터를 이동시켰다) => backEnd 부화 해결
데이터 베이스 부화 => 데이트 베이스를 분산(샤딩)시킴(데이터를 나눠서 저장)
=> 데이터 베이스를 긁어서 데이터를 꺼내오는데 시간이 오래걸림
=> 1. Redis라는 메모리(변수)에다 저장하고 꺼내오면 시간 빠름
2. JWT 토큰을 사용하면 데이터를 꺼내오지 않아도 됨, 회원 정보를 토큰에 암호화하고 백엔드에서 복호화해서 사용(인가 할때 DB를 안가고 백엔드에서 복호화)
토큰을 담아서 api요청을 보낼때 토큰이 만료되면 백엔드가 redirect라는 요청을 br에 보내면 br가 화면을 로그인화면으로 바꿈
=>>> 로그인을 하면(Br에서) backend에서 accessToken과 refreshToken을 줌
cookie = httpOnly, secure 옵션을 붙이면 보완이 좋아짐, refreshToken을 담아줌
토큰을 담아서 api요청을 보낼때, 만약 토큰이 만료가 된다면 UNAUTHENTED 에러를 BR에게 보냄.
_APP.TSX
MSA(Micro Servie Architecture).
인증과 인가를 Auth서비스(구글, 네이버, 로그인 백엔드 등)에서 하고 이외의 데이터 요청(API)는 Resou서비스에서 한다.Resou서비스는 사용 api에 따라 계속 서비스를 분화 시킬 수 있다.
장점: 각 서비스를 다른 언어로 할 수 있다. 한 서비스에 문제가 발생 했을 때 다른 서비스에는 지장이 없다.
단점: 복잡해졌다.
소셜 로그인(OAuth)
- 로그인을 담당하는 백엔드 서비스를 분화시키는 것(구글 네이버 카카오 로그인 등)
다른 api는
1.에러나면 실행 - 에러가 인가에러인지 체크
- RefreshToken으로 accessToken 재발급 요청(Auth서비스로) : refreshToken을 restoreAccessToken API로 요청(쿠키는 API 요청할떄 자동으로 들어간다)
- 발급받은 새로운 AccessToken을 state에 저장
- 방금 에러났던 API를 재요청(신규 ACCESStoken으로)
app.js에서 apolloClinet 세팅 전에는 useMutaion이나 usequerry 등은 못한다.
=>
Graphql-Request
Graphql
언더패칭 오버패칭 문제 해결
graphql은 endpoin 가 하나인 nestApi 이다
axios.post({query: "fetchBoard(){}, createBoard(){}") (여러개 보낼 수 있음)
=> post/graphql 에서 실행
axios.post()는 항상 성공(200)
