Rest API와 Web Socket
Backend와 Front가 자료를 주고받는 방식은 크게 API, Socket으로 나뉜다.
채팅을 구현하던 중 채팅방 목록을 어떤 방식으로 구현할지 고민에 빠졌다.
Rest API
rest api로 구현 시 구현 가능 방법은
- 페이지네이션 -> View Page가 바뀔 때 해당 Page 자료 호출.
- 전체목록, 참여목록, 1:1메세지 탭이 바뀔 때 해당 탭에 대한 자료 전체 호출.
- 전체를 호출 후 새로고침 버튼을 만들어 새로고침 클릭 시 전체 자료 갱신.
정도 있을 것 같다.
API 고려사항
채팅방 목록은 상태를 최신화가 중요하다고 생각했다. 그래서 새로운 데이터를 언제 받아올까 고민을 했었고, 새로고침 버튼 혹은 탭이나 페이지에 api호출을 넣는 방법을 생각했다.
- 전체 목록에 넣는 방법은 유저의 편의성이 좀 더 올라가는 대신 api호출의 횟수가 아마 더 많아질 것으로 예상된다.
- 새로고침은 유저의 편의성이 좀 내려가겠지만 api호출이 좀 감소하여 비용이 절약되는 효과를 볼 수 있다.
- 페이지에 넣는 방법은 api호출을 가장 많이 하겠지만 데이터를 가장 최신화로 유지할 수 있게되어 본인이 생각을 했을 때 밸런스가 가장 맞는 방법이라고 생각했다.
-> 이유는 채팅방 목록은 최신화가 중요하지만 소켓을 사용하지 않는다면 어느정도 api호출을 자주 해줄 필요가 있다고 생각한다.
페이지 마다 새로고침을 넣을까도 생각했지만. 페이지마자 새로고침을 눌러야해 사용자 경험이 매우 떨어질 것 같았다.
Web Socket
Web Socket으로 구현 시 구현 가능 방법은
- 전체자료 API호출 후 소켓으로 갱시되는 데이터들만 받기.
- 해당 페이지 API호출 후 해당 페이지에 대한 소켓 정보만 수정하기.
Scoket고려사항
Socket이 돌아가는 방법은 아직 Socket공부를 하지 않아 정확하게는 모르겠지만 일단 실시간으로 정보를 받아올 수 있을 것이다.
그럼 초기 데이터를 어떻게 받아오고 어느정도 유지하는지가 중요하다고 생각되고, 만약 소켓을 사용한다면 전체자료를 호출하고 전체 자료를 관리하는 방식이 좋을 것 같다고 생각했다.
결론
우리는 페이지네이션을 사용해 페이지가 바뀔 떄 api를 호출하고 소켓을 연결하지는 않기로 했다.
이유
채팅방 목록은 어느정도 데이터를 최신화할 필요가 있다고 생각하지만.
실시간으로 보여주는 것은 오버엔지니어링이라고 생각한다.
유저가 많아짐에 따라 서버를 유지하기 위해 필요한 자원이 방대해질 것이기 떄문에 채팅방 목록에서의 소켓 사용은 하지않기로 하였고.
전체를 받아오는 API VS 부분 부분 받아오는 API를 골랐을 때
부분 부분이 최신화하기 유리하다고 판단하여 부분 부분 받아오는 페이지 네이션 방식을 채택하게 되었다.
HIM