경고 : 응용 프로그램을 완료 할 남은 일이 거의 없습니다. 소켓을 통해 사용자 등록 화면, 백그라운드에서 알림 및 친구 요청 및 새로운 친구의 데이터 업데이트를 추가해야합니다.
현재, 응용 프로그램은 한 달 동안 각 기본 요구 사항을 구현하는 시간을 거쳐 한 달 동안 개발되었습니다.
기본 요구 사항이 완료되면 감지 된 새로운 요구 사항과 나머지 복잡한 요구 사항이 계속 구현 될 것입니다.
응용 프로그램 작성은 그래픽 인터페이스의 간단한 스케치로 시작되었습니다. 이 스케치는 이런 이유로 잃어 버렸습니다. 프로젝트 사진이 표시되는 마지막 섹션을 참조하십시오.
그래픽 인터페이스는 정적 테스트 데이터를 사용하는 동안 구현되었습니다.
이것은 지금까지 내가 한 오래된 프로젝트와 큰 차이가있는 첫 번째 프로젝트입니다. 나는 디자인 패턴을 사용하여 깨끗한 코드를 사용하고 비즈니스 논리를 보호 할 수있는 가장 논리적이고 최적의 방법으로 시도했습니다.
시간 제한에서 디자인이 구현되었습니다. 디자인은 벌집의 한계로 인해 약간 변경되어야했습니다 (메시지와 관련된 클래스 만).

빠르고 최적의 응용 프로그램을 제공하기 위해 장치 메모리에 메시지를 저장하기로 결정했습니다. 이 작업을 수행하기 위해 로컬 NOSQL 데이터베이스 역할을하는 Hive 도구를 사용했습니다.
최적의 솔루션으로, 새 메시지가 나올 때마다 채팅 화면이 사용자를 기다릴 필요가 없도록 RAM뿐만 아니라 장치에 저장합니다. 장치의 기존 변환의 마지막 메시지 만 RAM에 저장됩니다.
또한 사용자의 프로필 이미지는 사용자 장치에 저장되며 로컬 이미지의 주소는 RAM에 저장됩니다.
서버 로직을 보여 주려면 아래 이미지를 참조하십시오.

친구 요청을 다른 사용자에게 보내는 사용자의 세션을 시뮬레이션하는 이미지를 살펴보십시오.
Websockets의 사용이 언제 필요한시기와 REST API의 사용이 언제 필요한지 확인하기 위해 예제가 제공되었습니다.
메시지 보내기 및 친구 요청과 같은 실시간 작업은 WebSockets를 사용하는 동안 세션 열기 및 사용자 데이터 업데이트와 같은 작업은 나머지 API를 사용합니다.
이것은 여전히 연마 할 부분입니다. 주로 누락 된 것은 나머지 API 코드를 최적화하고 (보다 올바른 방법으로) 채널에 새 메소드를 추가하여 새 알림을 추가하고 사용자가 등록 할 수 있도록 나머지 API 및 채널에 메소드를 추가하는 것입니다.
더 나은 사용자 경험을 제공하려면 (속도의 의미에서) NOSQL 데이터베이스를 사용해야했습니다. 이러한 방식으로 사용자의 데이터에 더 빨리 액세스 할 수 있기 때문입니다.
분명히,이 생각은 신원 사이에 관계가 있기 때문에 주 사용자와 관련된 다른 사용자의 데이터가 업데이트되어야하기 때문에이 생각은 정확하다고 말할 수 없습니다.
곧이 섹션을 변경하고 리모델링 할 수 있습니다. 현재 모델의 논리는 매우 기본적입니다. 각 사용자는 아직 읽지 않은 메시지, 친구 인 사용자 이름, 친구 요청을 보낸 사용자 이름 및 사용자 이름, 이미지 (암호화)와 같은 데이터가 포함됩니다.
또한 Django는 아직 공식적으로 NOSQL 데이터베이스 통합을 가지고 있지 않다는 점에 유의해야합니다. 이러한 이유로 Djongo 도구를 사용했는데, 이는 매우 호기심이 많고 매우 유용합니다. 비즈니스 논리를 보호하기 위해 SQL 모델을 MongoDB에 적용합니다.



















