| (멀티잇 백엔드) |
소개
우선 반성 좀 하고 시작해야 할 것 같아요.. ㅎㅎ 주말이라 원래는 공부하고 코딩하고 문제 풀려고 했는데 토요일 아침에 일어나서 정보처리 공부했어요 엔지니어, 그러나 프로젝트와 관련된 다른 것. 그래서 원래 퍼블리싱용으로 받은 부트스트랩 템플릿으로 채팅파트를 만들려고 했는데 ㅠㅠ 제 의지력이 부족해서 못만들었습니다. 나는 그것을 너무 많이 후회했다. 몸 상태를 잘 관리하는 주말은 보통 가장 휴식을 취하는 시간입니다. 주말에 그냥 쉬는 것보다 의미 있는 일을 해야겠다는 생각이 들었다.오늘은 전체적으로 각 부분을 살펴보았습니다. 그 중 채팅 기능을 개발했습니다. 채팅 관련 부분은 제가 팀 내에서 센스가 별로 없어서 담당자가 전량 하려고 하던데요. 실제로 구현해본적도 없고 비교적 어려운 기능을 담당하고 있어서 걱정했는데 실력을 쌓고 새로운 기능에 대해 배울 수 있다는 생각에 어려운 일인데도 더 의욕이 생기고 잘 배워서 마스터하게 되었습니다. 어느 정도 실시간 통신 및 소켓. 해봐야 할 것 같아요라고 들었는데.. 실제로는 많이 못 잡았습니다. ㅎ 더군다나 제 MySql 커넥터가 이상해서 intellj가 db에 접속이 안되서 하루종일 에러를 보기가 좀 힘들었습니다. 내일 수정해야겠어요!
오늘 진행 세부 사항
전반적으로 오늘은 큰 진전이 없었습니다.. 서론에서 말했듯이 채팅 기능을 구현하는 방법에 대해 생각하고 전체 프로세스가 어떻게 진행되는지 Google에서 학습에 중점을 두었습니다.
결과적으로 두 가지 방법으로 채팅을 구현하는 방법생각
1. 메모의 개념으로 회원이 메시지를 보내면 실시간 소통으로 엮지 않고 동기||비동기
어떻게 보면 단순히 보낸 메시지를 저장했다가 보내는 포스트나 댓글 방식을 구현하는 방식과 비슷하다.
채팅 보내기 버튼 클릭 →채팅DB에 저장 → 채팅을 받는 사람이 페이지를 새로고침할 때(get)
→ 저장된 채팅DB에서 채팅 목록 로드
(채팅이 오면 확인하려면 페이지를 새로 고침해야하지만 비교적 쉽습니다.. 우리의 목표는 소셜 미디어이므로 부적절합니다)
+ 여기에서 사용자가 특정인과의 대화방에 들어갈 때 몇 초마다 자동으로 다시 로드하는 방법(비효율적으로 보임)
2. 소켓을 통한 실시간 통신으로 메시지를 송수신하고 메시지를 저장하여 방에 들어갈 때마다 미리 호출하는 방식
채팅 내용은 소켓을 통해 실시간으로 전달 및 조회됩니다. → 채팅 중 메시지를 보낼 때마다 db에 저장 -> 회원
채팅방 입장 시 최초 1회만 채팅DB에서 내용을 조회하여 순차적으로 호출
(저희가 생각하는 인스타그램 DM이나 카톡이랑 비슷해보이네요? 목적에 맞는데 난이도가 어려움 + db많이 차지)
+json으로 채팅방 나갈때만 저장하면 상대적으로 db가 덜 저장되지 않을까요? -> 어려울 것 같다..
이 방법들 중에서 저는 처음 두 가지 방법으로 소켓을 통한 실시간 통신을 구현할 계획입니다.
그 후 채팅 db에 대해 생각하고 채팅 엔터티를 만들었습니다. 그런 다음 jpa를 통해 mysql 및 jpaRepository에 연결하십시오.
생성이 되었는지 확인을 해보았지만 계속 같은 에러가 뜨길래 여기서 시간을 보냈으나 해결을 못했습니다.
내일 도움요청해서 수정해서 진행하도록 하겠습니다
정규시간이 끝나면 이번주 일요일은 정보처리기술자 실습의 날이니 실습에 집중하시기 바랍니다.
챕터 10까지 모든 문제를 풀고 앞부분을 다시 한번 복습하는 과정을 거쳤습니다.
채팅 프로세스 학습, 1. 채팅 테이블 생각과 엔터티 생성, 정보 처리 엔지니어 학습
나는 그것을 느꼈다
새로운 기술을 시도하는 것은 어렵고 아직 배워야 할 것이 많고 시도하려는 의지가 있습니다.전반적으로 소켓을 통한 채팅은 프로젝트에서 수행된 적이 없으며 상대적으로 어렵다는 것을 알고 있습니다. 그리고 처음에는 실시간 소통을 기반으로 ‘실시간 소통, 소켓을 통한 채팅은 채팅방을 나가면 사라진다’고 생각했고, 잠시 그 생각에 사로잡혔습니다. 그래서 기본적으로 테이블을 먼저 구상하고 채팅 기능을 구현할 프로세스를 고민했습니다. 그런 의미에서 모든 엔티티를 구상한 후 서버를 실행하여 jpa 저장소가 제대로 생성되었는지 확인했습니다. 에러를 보면 잘 모르겠고 intellj 내부에서도 MySql이 연결되지 않습니다. 오류는 아무리 찾아봐도 안나와서 정말 끈질기게 찾아봤지만 해결이 안되서 제 부족한점이 정말 와 닿았습니다.. 우선 프로젝트 개발이 중요해서 정말 한두시간 찾아 헤맸는데 못 찾았습니다. 동시에 전체적으로 저의 그동안의 개발과 공부방법은 많은 참고자료와 구글링을 통해서 이루어졌기 때문에 오류를 보아도 많은 감이 잡히지 않고, 구조를 보면 오류가 발생합니다. 전반적인 스프링과 JPA 구조를 모르겠습니다. 나는 생각했다. 프로젝트 완료 후, 기본적인 프레임워크와 메서드 등 API를 통해 오류를 잡아내고 학습하는 과정을 통해 어떻게 사용하느냐가 아니라 그 자체의 개념과 사용법을 알아야 좀 더 적절하고 효율적으로 사용할 수 있음을 체감한다. 오류 또는 실제 사용입니다. 대해 공부할 필요가 있다느낄 수 있었다
교훈
대체로 기본 api 문서를 통해 개념과 사용법을 익혀야 하는 기본 학습 및 구조의 중요성(오류를 잘 잡아내지 못해서 이런건 잘 몰라서 어디에서 오류가 발생했는지 빠르게 감을 못잡음.) 동기 및 비동기 실시간 통신을 위한 소켓 보유 개념마지막으로 jpa의 외래 키에 대한 조인 부분에 대해 더 많이 배울 수 있었습니다.
+ 개념 및 용어
! 실제 채팅 서비스를 구현할 때 뷰에서 채팅이 오면 바로 보여주는 방법을 알아봅니다.
= 동기식, 비동기식, 실시간(소켓)
javascript, JAVA 외부 API 등의 ajax 호출 시 데이터 교환을 위한 동기식 또는 비동기식 방법여부를 결정
동기식: 요청과 결과가 동시에 발생하여 요청이 생성되면 응답이 제공될 때까지 대기
– 요청과 응답이 동시에 발생합니다.
– 응답을 기다립니다
– 순차적으로 진행됩니다.
비동기(비동기식) : 요청과 결과가 동시에 발생하지 않습니다. 각 태스크 프로세스는 요청한 위치 X에서 결과를 기다리지 않기 때문에 순차적으로 진행
– 요청과 응답이 동시에 발생하지 않습니다.
– 응답을 기다리지 않고 다음 노드(요청)로 진행합니다.
– 주문은 보장되지 않습니다.
소켓
: 네트워크에서 데이터를 송수신하는 프로세스를 위한 실용적인 창구 역할을 함
= 프로세스가 데이터를 주고 받기 위해서는 소켓을 통해 주고 받아야 한다.
소켓 정의 = 프로토콜 + IP + 포트
즉, 소켓은 멀리 떨어진 두 호스트를 연결하고 인터페이스 역할을 하는 도구입니다. 데이터를 주고 받을 수 있는 구조입니다. 소켓을 통해 데이터 경로가 만들어집니다.
소켓 통신 흐름
HTTP 통신과 SOCKET 통신 비교
HTTP 통신
– 클라이언트의 요청이 있을 때만 서버가 응답하여 정보를 전송하고 즉시 연결을 종료하는 방식
| HTTP 통신 | SOCKET 통신 |
| 서버는 클라이언트가 요청을 보낼 때만 응답합니다. 단방향 통신 | 서버와 클라이언트는 지속적인 연결을 유지합니다. 양방향 통신 |
| 서버에서 응답을 받은 후연결 권리가 있습니다 끝 | 서버가 종료되거나 클라이언트가 종료하여 연결 해제 |
| 실시간 연결이 아닙니다. 필요하다면요청이 서버로만 전송되는 상황에 유용합니다. | 서버 및 클라이언트 실시간와 데이터를 교환할 때 사용 |
| 요청 보내기 서버 응답을 기다리는 중 주로 애플리케이션 개발에 사용 | 실시간 비디오 스트리밍이나 온라인 게임에 자주 사용됨 |