항해 7주차 클론코딩

이번주는 클론코딩 주차였다.

솔직히 crud를 한번 더 해서 연습량을 늘려보고싶었지만, 한분이 웹소켓을 해보는 것은 어떻겠냐는 말에 웹소켓을 하기로했다.

웹소켓은 클라이언트와 서버의 통신방법이다. http통신은 클라이언트에서 request를 보내면 그에따른 response값을 서버로부터 클라이언트가 받게 되는 형식이었다.

하지만 웹소켓은 클라이언트가 서버와 처음 handshaking을 하면 접속이 끊기기 전 까지 계속해서 통신을 주고 받는 것이다.

이 때 서버는 클라이언트의 특정 req가 없더라도 res를 보내 줄 수 있으며, 클라이언트 또한 연결이 되어 있다면 따로 제한 없이 데이터를 보내고 받을 수 있다.

 

우리는 다양한 웹소켓 툴 중 socket.io를 사용했다.

웹소켓을 통해 방을 만들어 채팅방을 만들수도 있고, 1:1 사설 채팅방을 만드는 기능을 만들 수도 있겠지만,

이번주에 우리는 노션이나 구글독스같은 동시적으로 많은 사람들이 제어하는 형태를 만들어 보고자 하였다.

 

처음에 시도했던 것은 useRef를 사용하여 onChange될 때마다 클라이언트에서 emit하는 것 이었다.

하지만 이렇게 사용하면 데이터가 이상하게 들어온다거나, 데이터가 들어오지 않는 등 다양한 문제가 있었다.

 

우리는 동시에 여러명이 한 페이지를 볼 때 textarea에 입력된 값이 동시적으로 변해야하였기 때문에 해당 문제를 해결할 방법이 필요했다.

그래서 우리는 quill라이브러리도 사용하기로 했다.

quill라이브러리는 사용자가 텍스트를 입력할 때 다양한 style의 텍스트를 입력할 수 있게 해주는 툴이었다.

quill로 특정 textarea같은 칸을 만들고, 그 안의 value값이 변할 때 마다 서버에 emit하고, 서버에서는 emit한 사용자를 제외한 나머지에게 broadcast.emit을 실행했다.

그랬더니 다양한 사용자가 서로 보내는 데이터를 잘 받고 잘 보내줄 수 있었다.

하지만 중간에 들어온 사용자는 접속 전 작성된 데이터들을 볼 수 없었다.

그리하여 quill의 contents가 변할 때 마다 emit을 하는데 이 때 새롭게 추가, 변경된 값과 quill내부의 전체 contents도 서버에 보내어 서버에서 전체 contents를 저장하도록 하였다.

그리고 중간에 들어온 사용자는 접속 했을 때 서버로부터 해당 데이터를 받도록 하였다.

 

지금 작성해보니 너무 쉬워 보일 수도 있지만, 실제로 프로젝트를 진행 할 때는 웹소켓도 익숙하지 않았었고, 동시적으로 제어하는 것을 어떻게 만들어야할지 감도 오지 않았었다.

그러던 중 quill이라는 라이브러리를 알게 되었고, 운이 좋게 잘 적용이 되었던 것 같다.

 

지금은 백엔드 서버를 닫아서 작동하진 않지만 해당 페이지의 text를 입력하는 창에서 모든 사용자가 입력하는 값을 동시에 보내고 받을 수 있었다.

bla-bla-Notion

 

GitHub - bla-bla-Notion/frontend

 

마지막까지 해결하지 못한 문제도 있었다.

우리는 서버에 한시간마다 전체 데이터를 저장하고, 클라이언트 단의 textarea의 input값을 비워주면서

왼쪽 리스트에 보여지는 리스트들을 리렌더링하고자 했는데 해당 부분은 시간이 부족해서 해결하지 못했다.

 

또한 textarea에서 각 사용자가 같은 줄에서 작성하면 데이터가 이상하게 작성되는 문제가 있었다.

이는 왜인지도 파악하지 못해서 너무 아쉬웠다.

 

이번 프로젝트로 느낀 점은 새로운 기술을 사용하고자 할 때는 공식문서가 정보를 정말 잘 주는지, 혹은 검색으로 얻을 수 있는 데이터가 충분한지를 미리 알아봐야한다는 것이다.

 

스코프는 굉장히 작았지만 시간도 1주로 짧았었고, 얻을수있는 데이터도 너무 적어서 힘들었다.

하지만 웹소켓이라는 통신방식을 알게되어 너무 뜻깊은 시간이었다.