¿Cuál es el propósito de tener una base de datos (almacenamiento persistente) en el lado del cliente de una aplicación web?

Por lo general, crea una base de datos del lado del cliente que contiene toda la información necesaria para representar la página que está mirando el usuario (y tal vez un poco más). De esa manera, la página se puede volver a representar localmente en respuesta a la entrada del usuario sin requerir que el servidor envíe el HTML actualizado.

Por ejemplo, en Facebook, es probable que haya una base de datos del lado del cliente que contenga el texto de las principales publicaciones, cuántos me gusta han recibido, cuáles son sus comentarios principales, etc. De esa manera, si visita una publicación individual, vaya De vuelta a su feed, se puede volver a representar sin esperar al servidor.

Hay un par de beneficios:

1. Su código de IU puede actuar como si la base de datos fuera local. Eso hace que el código sea síncrono y directo porque ninguna de sus escrituras o lecturas fallará. Por supuesto, cuando la sincronización de la base de datos falla, el resultado puede ser catastrófico.
2. El navegador y el servidor pueden ejecutar el mismo código (si se usa la misma API de base de datos en el cliente y el servidor, como lo es con Meteor). Eso puede salvarlo de escribir mucho código. En lugar de que la fuente de datos sea Mongo en el servidor y una API REST en el navegador, la fuente de datos puede ser Mongo en ambos extremos. Si el esquema es el mismo en ambos lugares, el código que lo usa funcionará en ambos lugares.
3. Cuando el usuario realiza cambios, puede ver los efectos de inmediato. ¡Imagínese si un Google Doc espera la opinión del servidor sobre el estado del documento después de cada cambio! Por supuesto, sin indicar que los datos no se guardan en la interfaz de usuario, el usuario puede pensar que algunos datos se guardan permanentemente cuando no lo está.
4. En el caso de Meteor, la API de red garantiza que todo su sitio siempre representa una vista coherente de la base de datos. Por ejemplo, si dos usuarios comentan una publicación aproximadamente al mismo tiempo, y su modelo de datos de código no tiene esta garantía, es probable que ambos usuarios vean su comentario primero y el otro usuario hasta que vuelvan a cargar la página. Si su base de datos del lado del cliente está sincronizada para tener una vista coherente como la base de datos del servidor, cuando los datos terminen de cargarse, ambos usuarios tendrán la misma vista.
5. Los usuarios pueden seguir utilizando el sitio, incluso con una cobertura de red irregular. Si alguna vez usó su teléfono mientras caminaba por el borde de una red wifi, entonces sabe lo frustrante que es cada vez. soltero. Presione el botón. murga. para. la red

Una razón es que muchos dispositivos no siempre están conectados a la red y aún pueden necesitar funcionar. Supongamos que tiene una aplicación que realiza encuestas o algo por el estilo (entrada de datos básicos), si puede almacenar los datos localmente, puede mantener la aplicación del lado del cliente funcional y enviar datos cuando el dispositivo tenga una conexión de red nuevamente

meteor hace eso porque es aún más rápido cuando tiene todos sus datos en el lado del cliente. Esto significa que solo tiene que esperar una vez para que regrese una llamada a la base de datos. después de eso se le enviarán actualizaciones. Y un beneficio adicional es que cuando pierde la conectividad, todavía puede usar la aplicación como si todavía estuviera conectada.