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.