Soy un desarrollador web de pila completa y actualmente construyo principalmente una aplicación de una sola página utilizando un marco de front-end como angular y un marco de back-end como Spring Boot.
Por lo general, el diseño de mi aplicación web (digamos que es un CRUD) es el siguiente: digamos que estoy en la página de actualización y actualizo una entidad. Luego se realiza una solicitud al backend que actualiza la entidad en la base de datos. Cuando el backend responde diciendo que todo está bien, su entidad ha sido actualizada (código de estado 200) voy a la página siguiente, que es la página de lectura con una URL como nombre de entidad entityName/{id} donde paso la identificación de la entidad a la siguiente página a través de la url. Luego, en la página de lectura, obtengo esa identificación, hago una solicitud al backend, recupero los datos de la entidad y los muestro.
El problema surge cuando el usuario pierde la conectividad a Internet, por lo que no se puede realizar la solicitud al backend y, en consecuencia, los datos no se pueden mostrar en la interfaz de usuario ni actualizar.
Otro diseño sería este: estoy en la página de actualización y actualizo mi entidad. Se realiza una solicitud al backend, pero también se mantiene el estado en el lado del cliente. Entonces, supongamos que se pierde la conectividad. Todavía puedo ir a la página de lectura y mostrar la entidad actualizada. Además, como el estado/los datos se mantienen en el lado del cliente, no tengo que hacer esa segunda solicitud al backend para obtener la entidad de la identificación, ya que la entidad vive en el lado del cliente. Durante el tiempo que el usuario pasó en la aplicación, la conectividad vuelve y se realiza la solicitud de actualización al servidor para sincronizar los datos en la base de datos y en el lado del cliente.
Me parece que el segundo enfoque es más conveniente para el usuario, ya que la interfaz de usuario no depende tanto de la solicitud realizada al backend para mostrar su información, haciéndola más fluida y agradable.
Sé muy bien que el primer enfoque está en uso. Me desarrollo así, por lo que mi pregunta es: ¿Es posible pasar del primer diseño al segundo diseño y, en caso afirmativo, con qué tecnologías?
Lo que haría para implementar el segundo diseño sería compartir datos entre componentes usando servicios (al implementar con angular). De esta manera, el estado de la aplicación se puede mantener en el lado del cliente. Pero tal vez hay una mejor manera. Escuché sobre la biblioteca NgRx para administrar el estado de una aplicación. ¿Es el camino correcto para administrar el estado de la aplicación en el lado del cliente?
También hay un segundo problema que es asegurarse de que las solicitudes que no se pudieron realizar cuando se perdió la conectividad se realicen cuando se restablezca la conectividad. Entonces me pregunto: ¿Es posible usar una herramienta que permita poner en cola las solicitudes y volver a ejecutarlas cuando la conectividad vuelva? Tengo noción de la aplicación web progresiva y los trabajadores del servicio, pero solo la noción (como sé que un trabajador del servicio puede usarse para almacenar en caché los datos intercambiados con el servidor) y me pregunto si es una forma de resolver este problema.
Espero sus comentarios en mi publicación. Espero que no haya sido demasiado largo. Gracias por adelantado.
Además, como el estado/los datos se mantienen en el lado del cliente, no tengo que hacer esa segunda solicitud al backend para obtener la entidad de la identificación, ya que la entidad vive en el lado del cliente.
Esto depende completamente de cuánto pueda confiar en el BE. Si se produce un error por cualquier motivo (¿token caducado/cerrado sesión? ¿Datos actualizados en otro cliente?), este enfoque puede volverse significativamente más complicado.
¿Es posible pasar del primer diseño al segundo diseño y, en caso afirmativo, con qué tecnologías?
Potencialmente, puede convertir su aplicación en una PWA y usar trabajadores de servicio . Encontré una buena guía para esto aquí . En caso de que el blog se caiga, pasa por el almacenamiento en caché de activos y fuentes en ngsw-config.json , luego retoca el almacenamiento en caché de la API. Así es como se vería el resultado final:
{ "$schema": "./node_modules/@angular/service-worker/config/schema.json", "index": "/index.html", "assetGroups": [ { "name": "app", "installMode": "prefetch", "resources": { "files": [ "/favicon.ico", "/index.html", "/manifest.webmanifest", "/*.css", "/*.js" ] } }, { "name": "assets", "installMode": "lazy", "updateMode": "prefetch", "resources": { "files": [ "/assets/**", "/*.(eot|svg|cur|jpg|png|webp|gif|otf|ttf|woff|woff2|ani)" ] } } ], "dataGroups": [{ "name": "api-freshness", "urls": [ "/timeline" ], "cacheConfig": { "strategy": "freshness", "maxSize": 100, "maxAge": "3d", "timeout": "10s" } }, { "name": "api-performance", "urls": [ "/favorites" ], "cacheConfig": { "strategy": "performance", "maxSize": 100, "maxAge": "3d" } } ] }"Para la estrategia de red primero, es frescura, para caché primero: rendimiento"
¿Es el camino correcto para administrar el estado de la aplicación en el lado del cliente?
Puede usar NgRx para almacenar en caché los datos de su aplicación, pero deberá asegurarse de que el caché esté siempre actualizado. Idealmente, usa un websocket para detectar cambios de BE, pero también podría potencialmente hacer sondeos.
Sin embargo, si todo lo que necesita es la funcionalidad fuera de línea, los PWA se sienten como el camino a seguir.
¿Es posible utilizar una herramienta que permita poner en cola las solicitudes y volver a ejecutarlas cuando se restablezca la conectividad?
Esta función se denomina sincronización en segundo plano y es una función de los trabajadores de servicios. Dicho esto, encontré este problema abierto al respecto. Podrías probar esto , pero se siente como un truco. Si fuera por mí, crearía una matriz de observables que se llaman cuando la conexión vuelve hasta que haya un mejor soporte de pwa para esto.