fullStackChatApp
1.0.0
Advertencia: queda poco para terminar la aplicación. Necesita agregar las pantallas de registro del usuario, las notificaciones en segundo plano y las actualizaciones de datos de las solicitudes de amistad y los nuevos amigos a través de sockets.
Por ahora, la aplicación se ha estado desarrollando durante un mes, un mes en el que pasó por períodos de tiempo implementando cada requisito básico.
Al completar los requisitos básicos, los nuevos requisitos detectados y los restantes más complejos continuarán implementándose.
La creación de la aplicación comenzó con bocetos simples de la interfaz gráfica. Estos bocetos se perdieron por esta razón, no puedo ponerlos aquí. Consulte la última sección donde se muestran las fotos del proyecto.
La interfaz gráfica se implementó mientras usaba datos de prueba estática.
Este es el primer proyecto que, con diferencia, tiene una gran diferencia con las viejas que he hecho. He intentado de la manera más lógica y óptima posible para usar patrones de diseño para tener código limpio y proteger la lógica comercial.
En un límite de tiempo, se implementó el diseño, diseño que tuvo que cambiarse un poco (solo las clases relacionadas con los mensajes) debido a las limitaciones de la colmena.
Para dar una aplicación rápida y óptima, he decidido guardar los mensajes en la memoria del dispositivo. Para hacer esto de una manera que he usado la herramienta Hive, que sirve como una base de datos local de NoSQL.
Como una solución óptima, cada vez que lleguen nuevos mensajes, los guardaré en el dispositivo, así como en la RAM para que la pantalla de chat no tenga que hacer que el usuario espere. Solo el último mensaje de las conversiones existentes del dispositivo se guardará en la RAM.
También aquí debe tenerse en cuenta que las imágenes de perfil de los usuarios se almacenarán en el dispositivo del usuario, mientras que las direcciones de las imágenes locales se almacenarán en la RAM.
Para demostrar la lógica del servidor, consulte la imagen a continuación.
Mire la imagen, que simula una sesión de un usuario que envía una solicitud de amistad a otro usuario.
El ejemplo se dio para ver cuándo se necesitaría el uso de WebSockets y cuándo el uso de la API REST.
Las operaciones en tiempo real, como enviar mensajes y solicitudes de amistad, utilizarán WebSockets, mientras que las operaciones como abrir una sesión y actualizar los datos de un usuario utilizarán la API REST.
Esta es la sección que queda por pulir. La falta principalmente de optimizar el código API REST (de una manera más correcta), agregue nuevos métodos a la parte de los canales para agregar nuevas notificaciones y agregar métodos a la API y los canales REST para que los usuarios se registren.
Para dar una mejor experiencia del usuario (en el sentido de la velocidad), era necesario usar una base de datos NoSQL, porque de esta manera se puede acceder a los datos del usuario más rápidamente.
Claramente, no se puede decir que este pensamiento sea correcto, porque dado que hay relaciones entre las identidades, los datos de otros usuarios relacionados con el usuario principal deberán actualizarse.
Pronto esta sección se puede cambiar y remodelar. Por ahora, la lógica del modelo es muy básica, cada usuario contendrá mensajes que aún no se han leído, nombres de usuario que son sus amigos, nombres de usuario que han enviado solicitudes de amistad y datos como nombre de usuario, imágenes (encriptadas) y más.
También se debe tener en cuenta que Django aún no tiene oficialmente integraciones de bases de datos NoSQL, por esta razón he usado la herramienta Djongo , que es muy curiosa y muy útil, aplica modelos SQL a MongoDB para proteger la lógica comercial.
