일단

풀스택으로서 앱이 작동하냐 안하냐는

1. 클라이언트 사이드 라우팅
2. refresh / access token 기반 만료가 정해진authenticate
3. serverside authorization
4. clientside authorization

프론트측 주요 로직

1. api 는 상태를 변경한다
2. 상태변화는 렌더를 야기한다.
3  따라서 렌더는 상태변화 혹은 api발송을 포함해서는 안된다. (상변화가 없는 api는 가능하다. 예를 들면 로그찍기)

4. 클라이언트사이드 라우트는 특정상태의 초기화를 요구한다
5. 그렇다고 렌더시점에 초기화를 진행하면 아까말했듯
렌더 ㅡ 상변화 ㅡ 렌더 ㅡ 상변화의 루프가 야기된다
6. 따라서 초기화는 렌더함수 이전에 초기화api를 먼저쏴야한다
7. 따라서 렌더는 상변화 api의 콜백으로 들어가야한다.
8. 상변화 api는 한두개가아닐수 있고 상변화api는 비동기로, 비순차적으로 발생 가능
9. 비순차적 동시 api의 경우에는 promise all과 같은것을 활용

10. dom은 재사용되지 않는다. 모든 렌더링은 새로운 dom을 생성한다
11. dom간 공유하는 글로벌상태가 있는 반면
하나의 dom이 보유하는 상태가 있다.
그 예시로는 nested dom이 있다.
dom이라는게 전역으로 만들어놓고 같은 객체에 계속 접근하며 변경하는것이 아니므로
dom 자체를 부모 dom의 상태로 저장해서
부모 dom은 매번 달라진 자식dom에 접근한다
12. 이 dom bounded state는 부모dom이 파기되면 같이 파기된다
13. 같이 파기된다는 뜻은 dom bounded state의 delete과정이 비교적 수월해진다는 뜻

14. global state의 해제는 수동으로 이루어져야한다
15. global state의 예시는
accesstoken
user info
등이 있다

16. global state를 많이쓸수록 상태관리가 어려워진다.
state의 수명을 dom의 생성과 파기 사이로 세팅하자

17. 라우팅은 초기화 api -> 콜백 렌더링으로 이루어진다고 했다.
근데 사실 그 이전에, 권한확인(인가) -> api -> 렌더
가 이뤄져야함

18. 클라이언트사이드에서 인증 인가를 통과시켜서 api를 쐈는데 api가 인증이나 인가 문제로 백엔드측에서 튕길경우
인증 인가 정보의 갱신이 필요한 시점이다.

19. 403이 아니면 그대로 에러핸들러1
20. 403이면 리프레쉬 진행후 (401은 쓰지 않는다. 리프레쉬는 인증 뿐 아니라 권한의 업데이트도 포함하기 때문) 다시시도하며, 이때에도 오류가 난다면, 해당 api의 접근권한이 진짜로 없는거로 판정.
21. 이때 재시도는 에러핸들러2

22. 즉 모든 api는 에러핸들러를 두개 가지며,
에러핸들러1의 디폴트는 nop
에러핸들러2의 디폴트는 로그아웃시키고 로그인페이지로 이동시키는것.(단, api가 만약 특별권한을 요구하는 경우는, 인증된 유저는 권한 구매페이지로 이동시키고 인증되지 않은유저는 로그인페이지로 이동시키는등 분기가 필요)

지금보면 시작하고 보니까 바로 프론트얘기만하게됨

백엔드는 인증인가 존나 쉬움



글구 프론트 제대로 만들려면

풀스택이어야함


풀스택은 그냥 프론트임.


프론트 백엔드의 통합이 굉장한 이점이 있음 진짜