¡Buena pregunta!
Construiría 2 clases de objetos: Mensaje y Usuario. Conectaría a los usuarios entre sí, a través de sus números de teléfono móvil, por ejemplo, para controlar quién puede enviar mensajes a quién.
El objeto Mensaje y la tabla de la base de datos solo serían un almacén de respaldo. Los mensajes reales se enviarán a través de notificaciones push, porque son instantáneos, y luego, cuando se abre la aplicación (o en segundo plano), los mensajes en una conversación particular se cargarán desde la base de datos.
- ¿Cuáles son los pros y los contras de lanzar una aplicación para iPhone en la tienda iOS de EE. UU. Como beta pública?
- Cómo obtener una pasantía en una empresa de desarrollo de aplicaciones móviles
- ¿Es este el momento adecuado para comenzar a aprender rápidamente a desarrollar aplicaciones realmente avanzadas y complicadas para dispositivos iOS o todavía debería trabajar con obj-c?
- ¿Por qué no puedo instalar iOS 8.3?
- ¿Qué determina el "orden de capas" de las vistas en iOS?
Como mínimo, un objeto de mensaje debe contener “from_user”, “to_user”, una marca de tiempo y el contenido del mensaje.
Por supuesto, podría preguntarse cuál es la forma más eficiente de estructurar su back-end. Puede imaginar que los campos relacionales, como las conexiones de amigo a amigo y “este mensaje pertenece al usuario X y al usuario Y” son costosos de consultar a mayor escala.
En ese caso, aunque depende exactamente de qué escala esté trabajando, le sugiero que organice mensajes alrededor de objetos de conversación.
Cuando el usuario A inicia una conversación de mensajería con el usuario B, se crea un objeto de conversación. El usuario B recibe la ID del objeto de conversación, y ambos usuarios comienzan a enviar mensajes al hilo de conversación. Ambos usuarios se mantienen actualizados en la conversación mediante push and pull.
Dado que el objeto Conversación no contiene ningún dato relacional, porque el usuario A y B “acuerdan” una ID de conversación, y dado que la conversación no se ordenará o indexará en el lado del servidor, en teoría debería ser más rápido que pesado. datos relacionales para consultar.
EDITAR: No creo que esta pregunta tuviera “Firebase” cuando la respondí. Eso cambia las cosas …
Firebase es NoSQL, lo que significa que tendrá que desnormalizar su base de datos, y no puede confiar mucho en consultas relacionales, búsquedas o tablas de unión.
Construiría un árbol simple, como este:
- / users / {$ uid} / {$ uid2} / {$ key} / [messages]
La raíz es / usuarios, el primer $ uid es la identificación del usuario actual y el segundo $ uid2 es la identificación del usuario con el que estoy chateando. Abrir una conversación es simplemente abrir el árbol en {$ uid2}.
El chat grupal ni siquiera necesita ser relacional, si está de acuerdo con copiar nuevos mensajes en el conjunto individual de mensajes de cada usuario en ese grupo. De lo contrario, podría simplemente hacer: / groups / {$ key} / [messages] y almacenar una referencia a todos los grupos en los que se encuentra un usuario como / users / {$ uid} / groups / {key} = true. Cuando un usuario abre un grupo, simplemente inicia la consulta en / groups / {$ key} y carga todos los mensajes.
Un malentendido común sobre Firebase es que es un buen sistema de base de datos de propósito general, como el antiguo Parse o el nuevo Parse Server. No lo es: Firebase suele ser útil cuando necesita datos no relacionales, en tiempo real. Ideal para una aplicación de chat, aplicación de lista de tareas, pero no tan bueno para las redes sociales, por ejemplo.
