¿Dónde poner la lógica de negocios si usa Firebase?

Estoy a punto de comenzar a desarrollar una aplicación web de una sola página que simplifica mucho un sistema de documentación multiusuario. El front end probablemente usará Angular2.

El proyecto tiene una fecha límite corta, por lo que he estado buscando "accesos directos", es decir, utilizando varios servicios listos para usar en lugar de implementar todo desde cero.

Necesitaré algún tipo de back-end para almacenar los datos de la aplicación. Miré a mi alrededor y encontré Firebase, que parece eliminar parte del trabajo de crear un back-end y API separados para comunicarse con el front-end.

Pero eso también significa que tendría que poner la lógica de negocios en el front-end, en la aplicación web Angular2, ¿verdad?

Entonces, si algún día en el futuro quisiera hacer una aplicación móvil, ¿tendría que duplicar el código de lógica de negocios?

Supongo que la alternativa sería crear un back-end que contenga la lógica empresarial y use Firebase para el almacenamiento de datos, pero eso parece un poco extraño (¿no podría simplemente usar un ORM o algo directamente en mi back-end para lograr el mismo resultado sin ¿mucho más trabajo?)

¿Cómo suelen las personas estructurar este tipo de aplicaciones, si quieren utilizar Firebase, por ejemplo?

P: Pero eso también significa que tendría que poner la lógica de negocios en el front-end, en la aplicación web Angular2, ¿ verdad ?

Si. Si no está respaldado por un servidor, la empresa debe implementarse en algún lugar.

Después de la adquisición de Google, Firebase evolucionó para convertirse en una plataforma para desarrolladores de aplicaciones móviles que no podían permitirse (o no necesitan) implementar su propio backend. Si bien la mayoría de los servicios son bastante transversales: almacenamiento, inicio de sesión, análisis y servicio de mensajes, es cierto que también proporciona Cloud Functions (tipo de lambdas) que se pueden usar para realizar algunas reglas específicas del negocio. Sin embargo, para aplicaciones empresariales o aplicaciones grandes con un dominio complejo y lógica de negocios, este tipo de soporte se queda corto.

Por lo tanto, como puede suponer, Firebase no nos exime de tener un backend dedicado a alojar y ejecutar operaciones específicas del negocio.

P: Entonces, si algún día en el futuro quisiera hacer un front-end de aplicaciones móviles, ¿tendría que duplicar el código de lógica de negocios?

No necesariamente. Si la aplicación web está construida en Angular, las plataformas cruzadas como NativeScript pueden permitirle reutilizar los componentes web, bibliotecas, utilidades, modelos, etc. No he profundizado en el tema, así que no puedo asegurarle una compatibilidad total. La clave se encuentra en TypeScript , tanto Angular como NativeScript requiere que codifiquemos en TS.

La cuestión es dónde alojar el Javascript para su distribución y versiones . Una palabra CDN .

P: Supongo que la alternativa sería crear un back-end que contenga la lógica empresarial y use Firebase para el almacenamiento de datos, pero eso parece un poco extraño (¿no podría simplemente usar un ORM o algo directamente en mi back-end para lograr lo mismo? resultado sin mucho más trabajo?)

Algunas consideraciones

Por un lado, alojar, implementar, administrar y mantener una base de datos no es poca cosa. Sin mencionar el manejo de la seguridad, la escalabilidad, la disponibilidad, etc. Por lo tanto, tener un proveedor de bases de datos que se ocupe de estas cosas es interesante. No es una idea loca en estos días tener nuestra base de datos en algún lugar de la nube. Por supuesto, no sugeriría esto si estuviéramos implementando el middleware y los back-end para un banco. Pero podría tener sentido para la sesión del cliente, los perfiles del usuario, las preferencias y este tipo de datos que generalmente viven en el lado del cliente o datos que no nos interesan.

Por otro lado, tener nuestro back-end es útil por una simple razón, desacoplamiento .

En lugar de acoplar a nuestros clientes a todo tipo de servicios que no administramos y controlamos, implementamos una aplicación del lado del servidor desde donde nos ocupamos de estas cosas para que nuestros clientes no tengan que preocuparse por problemas como el cierre de servicios o la interrupción cambios Además, ganamos en simplicidad porque nuestro back-end actúa como una fachada.

P: ¿Cómo suelen estructurar las personas este tipo de aplicaciones, si quieren utilizar Firebase, por ejemplo?

Varía mucho de un proyecto a otro. Por ejemplo, usamos Firebase + back-end.

• Firebase DB para compartir datos entre dispositivos-cuentas-sesiones . También como un registro de cambios, cuando nuestro backend no está disponible temporalmente, los clientes envían las operaciones de escritura al registro, que se sincroniza más tarde.

• Firebase Cloud Messages nos proporciona notificaciones y temas push ascendentes / descendentes. Utilizamos el servicio para el intercambio de mensajes de pub / sub.

• Análisis de Firebase Principalmente para métricas.

• Back-end para todo lo estrictamente relacionado con el negocio.

Respuesta corta: no use la lógica de negocios.

Respuesta larga: usted describe una aplicación que parece lo suficientemente pequeña como para no tener una lógica comercial separada; evalúe si realmente tiene esa lógica de negocios en primer lugar; El diseño de los datos puede reducir mucha lógica empresarial y un poco la capa de presentación. Muchos sistemas pequeños son en su mayoría CRUDOS y no tienen ninguna lógica comercial real; Muchas veces he visto dos o tres capas de clases que son solo objetos de paso que dejan espacio para un futuro que nunca llegará.

Puede comenzar con una API directamente desde Firebase, y luego introducir una capa adicional para la lógica empresarial cuando descubra que hay una necesidad real de ella, siempre que diseñe su contrato lo suficientemente bien como para que el servicio mantenga una firma estable mientras la implementación detrás puede cambiar.

ver /programming/54994228/how-to-minimise-firebase-function-latency

Cloud Firestore es la conexión principal y única entre el front-end y el back-end. Por supuesto, parte de la lógica puede estar dentro del front-end, pero por seguridad, generalmente solo puede ser para el beneficio del usuario fuera de línea. Debe implementar la seguridad en las propias colecciones de Cloud Firestore, asegurando roles o lo que necesite.

Luego, use las funciones de nube que se invocan desde un disparador de Cloud Firestore.

Nunca DEBE llamar a una función de nube desde una aplicación front-end.