nomad coder의 WebRTC 강의를 듣고 정리한 내용입니다. websocket vs http 둘다 프로토콜이다. 프로토콜이란 둘이 만났을 때 어떻게 일들이 진행될지 결정하고 어떻게 돌아가야할지에 대한 규칙을 만든다. 프로그래머는 이 규칙을 갖고 그를 따르는 코드를 만들어 실행한다. 표준이 되는 규칙, protocol 이 먼저 만들어져야하고, 개발자들이 이 규칙을 코드에 녹여내야한다. http stateless 브라우저가 요청을 해야 서버가 응답을 할 수 있다. websocket real-time 기능을 만들 수 있다 wss (secure websocket) 프로토콜을 사용한다.(wss://) 브라우저가 서버로 websocket request 를 보내면 서버가 받거나 거절한다. 악수가 한번 성립되면 연결이 establish 된다. 연결이 되어있기 때문에 서버는 유저를 기억할 수 있다. 연결이 되어있기 때문에 요청을 기다리지 않고도 메세지를 보낼 수 있다. bi-directio…

컴포넌트 추상화 공통적인 요소들을 추출해 불필요한 부분들을 생략하고 객체의 속성 중 중요한 것에만 중점을 두어 개략화(사전 : 대강 추리는 일) 하는 것 하나의 컴포넌트가 하나의 책임만을 담당한다. 책임이란 어플리케이션에서 컴포넌트가 하는 행동 컴포넌트들을 각각의 책임에 맞게 필요한 로직만으로 구성한다면 응집도가 높아지며, 다른 컴포넌트와의 결합도는 줄고 컴포넌트 특성상 외부로 노출할 필요가 없는 부분은 캡슐화가 될 것 컴포넌트는 이벤트 기반으로 스타일과 DOM 구조까지 고려하여 고유한 책임을 수행하게 되기에 버튼에 스타일을 적용하거나 클릭했을 때의 애니메이션을 넣거나 필요에 따라 색상과 폰트를 변경하거나 생각보다 다양한 것들이 책임을 수행하기 위해 고려되어야 한다. 텍스트와 같이 작은 책임 수행을 넘어서 레이아웃의 형태를 책임지는 컴포넌트, 서버와의 통신을 통해 데이터를 가져오는 컴포넌트, 특정 도메인에 관련된 비즈니스 로직을 수행하는 컴포넌트 등 범위가 확대될수록 이러한 책임을…

하단 토스 컨퍼런스 내용 clean code 개발할 때 병목이 되고 유지보수가 오래걸리며, 기능 추가가 불가능하거나, 성능이 안좋을 수 있는 코드는 다음과 같다. 흐름 파악이 어렵고 도메인 맥락 표현이 안되어 동료에게 물어봐야 알 수 있는 코드 읽기 좋은 깔끔한 코드는 코드 리뷰의 시간을 단축하며, 버그가 났을 때 디버깅 시간도 단축시킨다. 클린코드의 의의=유지보수(코드파악, 디버깅, 리뷰) 시간(시간=자원=돈)의 단축 나쁜 코드는 하나의 목적인 코드가 흩뿌려져 있는 경우 다 떨어져 있어 나중에 기능을 추가할 때 스크롤을 위아래로 이동하며 미로찾기를 해야함 하나의 함수가 여러가지 일을 하고 있는 경우 세부 구현을 모두 읽어야 함수의 역할을 알 수 있다. 코드 추가 및 삭제도 시간이 걸림 함수의 세부 구현 단계가 제각각일 경우 큰 그림을 보며 리팩토링 하면 함수 세부 구현 단계 통일 하나의 목적인 코드는 뭉쳐두기 하나의 함수는 한가지만 하도록 쪼개기 ⇒ 클린코드란 짧은 코드가 아닌 …

사용시 이점 중간에 service worker를 통해서 네트워크 요청을 가로채고 모의 응답을 받아 반환하기 때문에 기존 data fetch 로직을 그대로 사용하여 mock 데이터를 반환 받을 수 있다. 그렇기 때문에 api 가 혹시라도 늦게 나온다고 하더라도 사전에 api spec 만 미리 맞춰놓는다면 네트워크 요청 로직을 미리 작성해 놓고 그대로 사용하여 테스트할 수 있다. 데이터를 하드코딩 하거나 mock server를 만든다고 하더라도 추후에 url 및 엔드포인트 변경이라던가 네트워크 요청 로직을 다시 작성할 필요가 있는데, msw는 그에 비해 on/off 하듯이 기존에 필요한 로직을 그대로 사용하여 원하는 데이터를 조작하여 사용할 수 있어 백엔드와 개발 시점이 겹친다고 하더라도 일정이 미뤄지지 않고 개발할 수 있다. 원하는 테스트를 진행하기 위해 db 조작을 따로 요청할 필요 없이 mock 데이터를 생성해 테스트할 수 있다. header, cookie 등 네트워크 요청시 사…