Pushpin: Soporte del navegador

Creado en 6 nov. 2019  ·  9Comentarios  ·  Fuente: automerge/pushpin

Soy consciente del escepticismo de

Me gustaría aún mejor si funcionara en (capacidad limitada) incluso si el backend está fuera de rango. A partir de electron, solo significaría que el front-end se carga en el proceso de renderizado mientras que el backend se carga en el proceso de fondo.

¿Es esto demasiado loco? o demasiado trabajo? ¿O tal vez existen limitaciones específicas que serían difíciles o imposibles de superar?

Solo quiero darle vueltas a esta idea, principalmente porque considero que los costos iniciales de instalación de una aplicación electron son muy altos en comparación con probarla en el navegador e instalar la aplicación por conveniencia.

Comentario más útil

Sí, me encantaría convertir al trabajador "en segundo plano" en un trabajador de servicios y hacer que la chincheta funcione como PWA. ¡Ese es el sueño!

Todos 9 comentarios

¡Estoy a favor de la compatibilidad con el navegador! Creo que podríamos ejecutar el front-end en el navegador y el back-end en un proceso de nodo.

Dicho esto, el front-end es solo un hilo de renderizado. Necesita tener un back-end presente con un front-end en todo momento para hacer algo realmente interesante. Creo que podríamos imaginar un ... mid-end que estaría más cerca de lo que estás buscando para Gozala y subcontratar más responsabilidad a un back-end compartido.

Dicho esto, es un objetivo de ingeniería explícito (pero posiblemente modificable) para este proyecto que sea autónomo. No se requieren servicios externos para que funcione. Nada más en lo que instalar o confiar.

Para ser específico, lo que estoy pensando en backend son piezas que brindan capacidades de red y sistema de archivos. Idealmente, el frente debería poder persistir los cambios en la caché del frontend si el backend está inactivo.

¿Hay alguna razón por la que los cambios locales / fuera de línea no puedan persistir en el front-end y replicarse en el backend una vez que estén disponibles? Eso es diferente a la complejidad de la implementación, obviamente.

Bueno, persistir en las cosas es el trabajo del backend. Eso es lo que estoy tratando de decir. El front-end es un único hilo de renderizado que no persiste. Esta es una propiedad importante y esencial del front-end. Si quisiera tener una especie de mid-end que persistiera localmente y pudiera operar sin el back-end, ¿por qué no convertirlo en un par completo?

La razón por la que el front-end no persiste es porque la persistencia, el cálculo CRDT y todo eso bloquea el hilo de entrada.

Bueno, persistir en las cosas es el trabajo del backend. Eso es lo que estoy tratando de decir. El front-end es un único hilo de renderizado que no persiste. Esta es una propiedad importante y esencial del front-end. Si quisiera tener una especie de mid-end que persistiera localmente y pudiera operar sin el back-end, ¿por qué no convertirlo en un par completo?

Muy bien, estoy dispuesto a adoptar una terminología de gama media. Sin embargo, no estoy del todo seguro de lo que significa "par completo" en este contexto.

La razón por la que el front-end no persiste es porque la persistencia, el cálculo CRDT y todo eso bloquea el hilo de entrada.

Los navegadores tenían subprocesos de trabajo desde hace bastante tiempo. Son una buena opción para este tipo de cosas, de hecho, con los trabajadores de servicio, incluso podría ejecutar todas las cosas mientras está totalmente fuera de la red y con el proceso de back-end fuera de rango.

Sí, me encantaría convertir al trabajador "en segundo plano" en un trabajador de servicios y hacer que la chincheta funcione como PWA. ¡Ese es el sueño!

Para el trabajador, puede hacer una persistencia a más largo plazo en el navegador con algo como IndexDB incorporado o soluciones de almacenamiento "nativas del navegador" similares, aunque hay algunas advertencias importantes. ¿Alguien está trabajando en esto actualmente?

¿Fue útil esta página
0 / 5 - 0 calificaciones