Où mettre la logique métier si vous utilisez Firebase?

Je suis sur le point de commencer à développer une application Web d'une seule page qui est très simplifiée, un système de documentation multi-utilisateurs. Le frontal utilisera probablement Angular2.

Le projet a un court délai, donc je cherchais des "raccourcis", c'est-à-dire en utilisant divers services prêts à l'emploi au lieu de tout mettre en œuvre à partir de zéro.

J'aurai besoin d'une sorte de backend pour stocker les données de l'application. J'ai regardé autour de moi et j'ai trouvé Firebase, qui semble enlever une partie du travail de création d'un backend et d'une API séparés pour communiquer avec le frontal.

Mais cela signifie également que je devrais mettre la logique métier à l'avant, dans l'application Web Angular2, non?

Donc, si un jour, je souhaite créer un frontal d'application mobile, je devrais dupliquer le code de logique métier?

Je suppose que l'alternative serait de créer un backend qui contient la logique métier et utilise Firebase pour son stockage de données, mais cela semble un peu bizarre (ne pourrais-je pas simplement utiliser un ORM ou quelque chose directement dans mon backend pour obtenir le même résultat sans beaucoup plus de travail?)

Comment les gens structurent-ils généralement ces types d'applications, s'ils souhaitent utiliser Firebase par exemple?

Q: Mais cela signifie également que je devrais mettre la logique métier en front-end, dans l'application web Angular2, non ?

Oui. S'il n'est pas soutenu par un serveur, l'entreprise doit être implémentée quelque part.

Après l'acquisition de Google, Firebase a évolué pour devenir une plate-forme pour les développeurs d'applications mobiles qui ne pouvaient pas se permettre (ou n'avaient pas besoin) de déployer leur propre backend. Bien que la plupart des services soient assez transversaux: service de stockage, de connexion, d'analyse et de messages, il est vrai qu'il fournit également des fonctions cloud (sorte de lambdas) qui peuvent être utilisées pour exécuter certaines règles spécifiques à l'entreprise. Cependant, pour les applications d'entreprise ou les applications volumineuses avec un domaine et une logique métier complexes, ce type de support est insuffisant.

Ainsi, comme vous pouvez le deviner, Firebase ne nous dispense pas d'avoir un backend dédié à l'hébergement et à l'exécution d'opérations spécifiques à l'entreprise.

Q: Donc, si un jour je souhaite créer une application frontale pour les applications mobiles, je devrai dupliquer le code de la logique métier?

Pas nécessairement. Si l'application Web est construite sur Angular, des plates-formes croisées comme NativeScript peuvent vous permettre de réutiliser les composants Web, les bibliothèques, les utilitaires, les modèles, etc. Je ne me suis pas plongé dans le sujet, je ne peux donc pas vous assurer une compatibilité totale. La clé repose sur TypeScript , Angular et NativeScript nous oblige à coder sur TS.

Il s'agit alors de savoir où héberger le Javascript pour sa distribution et sa version . Un mot CDN .

Q: Je suppose que l'alternative serait de créer un backend qui contient la logique métier et utilise Firebase pour son stockage de données, mais cela semble un peu bizarre (ne pourrais-je pas simplement utiliser un ORM ou quelque chose directement dans mon backend pour obtenir le même résultat sans beaucoup de travail?)

Quelques considérations.

D'une part, l'hébergement, le déploiement, la gestion et la maintenance d'une base de données n'est pas une mince affaire. Sans parler de la gestion de la sécurité, de l'évolutivité, de la disponibilité, etc. Donc, avoir un fournisseur de base de données qui s'occupe de ces choses est intéressant. Ce n'est pas une idée folle de nos jours d'avoir notre base de données quelque part sur le cloud. Bien sûr, je ne suggérerais pas cela si nous implémentions le middleware et les back-ends pour une banque. Mais cela pourrait avoir un sens pour la session du client, les profils de l'utilisateur, les préférences et ce type de données qui vivent généralement du côté client ou des données qui ne nous intéressent pas.

D'un autre côté, avoir notre back-end est utile pour une raison simple, le découplage .

Au lieu de coupler nos clients à toutes sortes de services que nous ne gérons pas et ne contrôlons pas, nous déployons une application côté serveur à partir de laquelle nous nous occupons de ces choses afin que nos clients n'aient pas à se soucier de problèmes tels que les fermetures de services ou les interruptions. changements. De plus, nous gagnons en simplicité car notre back-end agit comme une façade.

Q: Comment les gens structurent-ils généralement ce type d'applications, s'ils souhaitent utiliser Firebase par exemple?

Cela varie considérablement d'un projet à l'autre. Par exemple, nous utilisons Firebase + back-end.

• Firebase DB pour partager des données entre les périphériques-comptes-sessions . Également en tant que journal des modifications, lorsque notre serveur principal est temporairement indisponible, les clients envoient les opérations d'écriture au journal, qui est synchronisé ultérieurement.

• Firebase Cloud Messages nous fournit des notifications push et des sujets en amont / en aval. Nous utilisons le service pour l'échange de messages pub / sub.

• Analyses Firebase Principalement pour les mesures.

• Back-end pour tout ce qui est strictement lié à l'entreprise

Réponse courte: n'utilisez pas la logique métier.

Réponse longue: vous décrivez une application qui semble suffisamment petite pour ne pas avoir de logique métier distincte; évaluer si vous avez vraiment une telle logique métier en premier lieu; une grande partie de la logique métier peut être réduite par la conception des données et un peu par la couche de présentation. De nombreux petits systèmes sont pour la plupart CRUD et n'ont pas de véritable logique métier; Souvent, j'ai vu deux ou trois couches de classes qui ne sont que des objets passthrough laissant un espace pour un avenir qui n'arrivera jamais.

Vous pouvez commencer avec une API directement à partir de Firebase, puis introduire une couche supplémentaire pour la logique métier lorsque vous constatez que vous en avez vraiment besoin, tant que vous concevez suffisamment votre contrat pour que le service conserve une signature stable pendant que le la mise en œuvre derrière peut changer.

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

Cloud Firestore est la connexion principale et unique entre le front-end et le backend. Bien sûr, une certaine logique peut se trouver dans le front-end, mais pour la sécurité, cela ne peut généralement être que hors ligne pour le bénéfice de l'utilisateur. Vous devez implémenter la sécurité sur les collections Cloud Firestore elles-mêmes, en sécurisant les rôles ou tout ce dont vous avez besoin.

Ensuite, utilisez les fonctions cloud appelées à partir d'un déclencheur Firestore Cloud.

Vous NE DEVEZ JAMAIS appeler une fonction cloud à partir d'une application frontale.