211209 백엔드, 마이크로프론트엔드

211209

백엔드

• 201 데이터가 잘 만들어졌습니다 상태 코드
• 204 정상적으로 삭제 했고 이제 리소스가 없음. sendStatus(204) → 상태 메세지만 반환함.
• postman 에서 RUN 버튼 누르면 컬랙션 안에 모든 API를 테스트할 수 있다.
• mvc 패턴 model, view, controller 를 분리하는 패턴 model (DB), controller(logic), View(ui) → 서버에서 View 는 router 와 밀접한 관련이 있다.
• typescript 에서 req.query 에 타입을 정의하고 싶을때 req: Request<{}, {}, {}, Type> 으로 정의할 수 있다.
• 마찬가지로 body 나 params 의 타입을 설정하고 싶다면 Request 에 generic 으로 순서에 맞게 넣어주면 된다.

마이크로 프론트엔드

• 각각의 페이지를 각각의 SPA로 만든다. 서로 커뮤니케이션을 하는 것이 아니라 API를 통해 커뮤니케이션 하게 만든다.
• 장점? 완전히 독립적인 앱 두게를 갖게 된다. 만약 각각의 팀이 개발하고 있다면? 각각의 팀이 독립적인 결정을 해도 영향을 주지 않는다!
• 예를들어 팀 1에서는 react로 구현하고 팀2 에서는 vue 나 angular 같은걸로 개발할 수 있게 된다.
• 한 페이지 내에서도 가능하다. 근데 각각의 앱을 어디에 표시할지 어떻게 알까? 컨테이너라는 앱도 만들어서 어떻게 표시할지 구현할 수 있다. 즉 2개의 마이크로프론트 앱이 있다면 한개의 컨테이너 앱을 더 두어서 어떻게 배치할지 정하는 것이다.
• 컨테이너를 어떻게 구현할수 있을지는 크게 3가지 관점이 있다.
  1. build time integration → 브라우저에 컨테이너가 로딩 되기 전에 각각의 앱에 접근할 수 있다.
  2. run time integration → 브라우저에 컨테이너가 로딩 된 이후에 각각의 앱에 접근할 수 있다.
  3. server integration → backend 에서 해야할 내용이므로 여기서는 다루지 않는다.
• build tim integration에 가장 간단한 방법?
  • 작업 완료하면 npm 패키지로 배포한다. 다음 컨테이너에서 받아서 사용한다.
  • 장점 : 쉽다. 이해하기 쉬움.
  • 단점 : container 가 redepoly 되면 패키지도 다시 update 됨. 컨테이너와 강하게 결합되게 된다. 마이크로론트엔드에 컨셉에 맞지 않음.

알고리즘

• 실제로 재귀 함수로 DFS 구현하는 경우가 있다.
• BFS 는 보통 큐라서 만약 둘다 가능하다면 BFS로 푸는게 나은 경우가 많다.
• 100만 → o(N) 만큼 필요함