Document Object Model로 HTML이란 코드로 설계된 웹페이지가 브라우저 안에서 화면에 나타나고, 이벤트에 반응하며 값을 입력받는 등 기능들을 수행할 객체들로 실체화된 형태를 의미합니다.
그러나 SPA를 많이 사용하게 되면서 DOM tree를 바로 바로 변경해야하는 일이 생겼는데, DOM 조작을 더 효율적으로 할 수 있도록 등장한 것이 Virtual DOM 입니다.
Virtual DOM : 실제 DOM을 모방하는 형태로 메모리 상에서만 존재하는 가상의 DOM을 의미합니다. = DOM의 복사본
데이터가 변경이 되면 전체 UI는 Virtual DOM에 렌더링 되어져 이전 Virtual DOM에 있던 내용과 업데이트 후에 내용을 비교하여 바뀐 부분만 실제 DOM에 적용시키게 됩니다.
순수 자바스크립트는 리엑트에 비해 훨씬 가벼워 작은 규모의 프로젝트에서 사용하는게 효율적이지만, 대규모 프로젝트로 넘어가게 되는 경우
복잡한 UI개발에는 한계가 있어서 리엑트를 사용하는게 훨씬 효율적입니다. ( 이유: Virtual DOM, 컴포넌트 기반, JSX문법 가독성, 유지보수, 등등의 장점이 있음 )
매번 Props로 내려주게 되면 발생하는 문제점인 Props drilling을 방지할 수 있다.
Props Drilling이 많아질 경우 Prop의 출처를 찾기 어렵고 코드가 복잡해진다.
외부 데이터를 가져와 사용하는 컴포넌트와 브라우저 이벤트에 의존하는 컴포넌트들을 순수 함수 컴포넌트로 만들어 줄 수 있다는 장점이 있어서 사용합니다.
브라우저 이벤트는 예측할 수 없고, 이벤트에 대한 처리는 언제나 다른 결과를 가져올 수 있으므로, 브라우저 이벤트에 의존하는 컴포넌트는 순수 함수 원칙을 어기게 됨
동기식 프로그래밍은 요청을 보낸 후 응답을 받아야만 다음 동작이 이루어지지만, ( 어떤 작업이 수행중이라면 그 뒤의 작업은 대기 )
비동기식 프로그래밍은 현재 작업의 종료여부와 무관하게 다음 동작을 실행합니다. ( 완료 순서가 보장되지 X )
동기식 프로그래밍은 작업 중단이 발생하지만, 비동기식 프로그래밍은 작업 중단이 발생하지 않습니다.
동기 : 순차적, 직렬적으로 발생
비동기 : 병렬적으로 발생
Single Page Application (SPA) 는 서버에 한 번 리소스 요청을 하고 그 뒤에는 필요할 때 데이터만 받아와서 기존 페이지를 수정해주는 방식을 사용합니다. 사용자 입장에선 깜빡임이 없고 자연스러운 UX를 경험할 수 있다는 장점이 있습니다.
Multi Page Application (MPA)는 여러개의 페이지로 이루어져 있어, 하나의 변경사항에도 리렌더링 , 페이지가 갱신되는 상황이 많습니다.
웹사이트를 호스팅하는 웹 서버의 위치 조회 -> 웹 서버에 연결 -> 특정 페이지를 가져오기 위한 요청 전송 -> 웹 서버의 응답 처리 -> 사용자가 각 웹사이트와 상호 작용할 수 있도록 페이지를 렌더링
DNS / IP주소 / HTTP
클라이언트 상태관리는 Recoil, 서버 상태관리는 React Query를 사용했습니다.
Recoil이 Redux toolkit 보다 더 간단한 구조를 가지고 있고, Redux 대비 보일러플레이트 코드가 적고 사용이 간편합니다.
Selector로 비동기 처리가 가능하기 때문에 따로 미들웨어를 처리할 필요가 없어 선택했습니다.
그러나 데이터 페칭 라이브러리를 별도로 설치해야 해서 우리에게 친숙한 Hook을 사용하여 자연스럽게 서버 데이터를 사용할 수 있는 React Query를 선택하게 되었습니다.
state는 React의 내장 객체이기 때문에 State를 직접적으로 변경하면 기존 객체의 참조에선 변경사항이 반영되지 않습니다.(불변성)
따라서 React가 변경사항을 인지하게 하기 위해선 setState를 통해 State를 변경해줘야 합니다.
클라이언트 사이드 렌더링 (CSR)은 브라우저에서 요청한 즉시 자바스크립트를 이용해서 전달합니다.
서버 사이드 렌더링 (SSR)은 브라우저에 접속하는 순간 서버에서 HTML을 만들어서 전달해줍니다.
쉽게 요약하면 CSR은 페이지의 내용을 브라우저에서 그려주고, SSR은 서버에서 페이지의 내용을 다 그려서 브라우저에 던져줍니다.
장단점
CSR
장점 : 동적으로 빠르게 렌더링이 되기에 좋은 UI를 가지고 있고, 초기 로딩 이후 구동 속도가 빠르고 서버 부하를 분산시킵니다.
단점 : 초기 로딩 속도가 느리고, SEO가 어려운 단점이 있습니다.
SSR
장점 : 초기 로딩 속도가 빠르고, SEO에 유리합니다.
단점 : 매번 페이지를 요청할 때마다 새로고침이 발생하여 화면이 깜빡임 -> 좋지 않은 UI를 초래한다.
실시간 채팅 기능 구현을 하기 위해 supabase에서 제공하는 리얼타임 기능이 구현 효율을 높여주고, 테이블을 직접 구성하여 데이터 구조를 설정할 수 있는 장점이 우리 사이트에 적합한 데이터베이스라고 판단하여 사용했습니다.
supabase 데이터 베이스 테이블에 초기 설정 을 하고 schema viusalizer통해 ERD를 구성,
구성한 로직을 바탕으로 supabase docs를 참고하여, 코드를 세팅해서 각 테이블의 기능을 구현 (
새로운 state를 하나 만들어 둔 뒤 qna table을 불러 올 때 new Map 함수를 이용하여 중복된 id값을 한번 걸러 준 뒤 state에 저장, auth.user.id를 room_id와 연동 후 메세지 보낸 사람의 uuid를 채팅방 room_id로 만들어 접근시 해당 uuid를 가진 유저의 채팅만 출력되도록 eq에 id값을 한번 걸러 준 state를 넣어 구현하였다 )
하나의 채팅방이 생성이 될때마다, 채팅방에 속해 있는 유저들을 그리고
그들이 주고 받은 메시지를 각각의 테이블에 insert하여 유기적으로 기능하도록 구현을 하였다.