如果使用Firebase，在哪里放置业务逻辑？

10

我将开始开发一个单页面Web应用程序，该应用程序非常简化了多用户文档系统。前端可能会使用Angular2。

该项目的期限很短，因此我一直在寻找“捷径”，即使用各种现成的服务，而不是从头开始实现所有内容。

我将需要某种后端来存储应用程序数据。我环顾四周，发现Firebase，它似乎取消了创建单独的后端和API以与前端通信的工作。

但这也意味着我必须将业务逻辑放在Angular2 Web应用程序的前端，对吗？

因此，如果我将来某天想做一个移动应用程序的前端，我是否必须复制业务逻辑代码？

我想替代方案是创建一个包含业务逻辑并使用Firebase进行数据存储的后端，但这似乎有点不可思议（我不能只在后端使用ORM或其他东西来获得相同的结果，而无需还有很多工作吗？）

例如，如果人们想使用Firebase，人们通常如何构造这类应用程序？

— 马格努斯W
source

您最熟悉哪个数据库/ orm等？那可能是使您最快到达那里的原因。

— 罗伯特·哈维

对于这个项目，我可能会使用一些以前从未使用过的技术，因此无论哪种方式都可以学习……

— Magnus W

您只需要数据存储还是在尝试利用即时推送功能？如果您不认为这是业务逻辑，那么每种前端技术都可以使用其自己的连接代码直接对其进行处理。不确定ORM是否会这样做。

— JeffO

2

问：但这也意味着我必须将业务逻辑放在Angular2 Web应用程序的前端，对吗？

是。如果没有服务器支持，则应在某处实施业务。

在Google收购之后，Firebase演变成一个移动应用程序开发人员的平台，这些开发人员负担不起（或不需要）部署自己的后端。尽管大多数服务都是横向的：存储，登录，分析和消息服务，但确实它还提供了Cloud Functions（某种lambda），可用于执行某些特定于业务的规则。但是，对于企业应用程序或具有复杂域和业务逻辑的大型应用程序，这种支持不足。

因此，您可能会猜到，Firebase不会免除我们拥有专门用于托管和运行业务特定操作的后端的权利。

问：因此，如果将来有一天我想做一个移动应用程序的前端，我是否必须复制业务逻辑代码？

不必要。如果该Web应用程序是基于Angular构建的，则诸如NativeScript之类的跨平台可能允许您重用Web组件，库，实用程序，模型等。我没有深入研究该主题，因此无法保证完全兼容。关键在于TypeScript，Angular和NativeScript都要求我们在TS上进行编码。

然后，问题是在何处托管Javascript以进行发布和版本控制。单词CDN。

问：我想替代方案是创建一个包含业务逻辑并使用Firebase进行数据存储的后端，但这似乎有点不可思议（我不能仅在后端使用ORM或其他东西来实现相同功能结果，而无需进行更多工作？）

一些注意事项。

一方面，托管，推出，管理和维护数据库并非易事。更不用说处理安全性，可伸缩性，可用性等了。因此，让数据库提供者来照顾这些事情很有趣。如今，将我们的数据库存储在云中并不是一个疯狂的想法。当然，如果我们为银行实现中间件和后端，我不会建议这样做。但这对于客户端的会话，用户的配置文件，首选项以及通常驻留在客户端的此类数据或我们不关心的数据可能是有意义的。

另一方面，出于简单的原因，将我们的后端去耦是有用的。

与其将客户耦合到我们不管理和控制的各种服务上，我们还从那里管理这些事情来部署服务器端应用程序，从而使我们的客户不必担心服务关闭或中断等问题。变化。此外，由于后端的作用就像立面一样，我们获得了简单性。

问：例如，如果人们想使用Firebase，人们通常会如何构造这类应用程序？

各个项目的差异很大。例如，我们使用Firebase +后端。

Firebase DB在device-accounts-sessions之间共享数据。同样作为变更日志，当我们的后端暂时不可用时，客户端会将写入操作发送到日志，该日志随后将同步。
Firebase Cloud Messages向我们提供上游/下游推送通知和主题。我们使用该服务进行发布/订阅消息交换。
Firebase分析主要用于指标。
后端所有与业务严格相关的内容

— 莱夫
source

1

简短的回答：不要使用业务逻辑。

长答案：您描述的应用程序看起来足够小，没有单独的业务逻辑。首先评估您是否真的有这种业务逻辑；数据设计可以减少很多业务逻辑，而表示层则可以减少一些业务逻辑。许多小型系统大多是CRUD，没有任何实际的业务逻辑。很多时候，我已经看到两到三层的类只是传递对象，为将来永远不会到达的未来留有空间。

您可以从Firebase开始使用API，然后在发现确实有需求时再引入业务逻辑的附加层，只要您对合同的设计足够好，以使服务能够在签名时保持稳定的签名即可。后面的实现可能会改变。

— 布鲁诺·瓜迪亚
source

不能说，因为我同意这一点。我已经在这个行业工作了20年，并一直在小型CRUD应用程序中工作，但是几乎总是有一些业务逻辑。即使只是自定义验证或税收计算，总会有一些东西。

— 朱尔斯（Jules）

我同意你的评论。我并不是说业务逻辑为零。我的意思是说，它还不够大，不值得单独放置一层。我会说这些验证或计算是否确实属于业务层而不属于数据或表示层（特别是自定义验证往往符合我对数据逻辑的定义），但是重点并不是要对它进行分类，而是在哪里编码实用。

— 布鲁诺·瓜迪亚

0

参见/programming/54994228/how-to-minimise-firebase-function-latency

Cloud Firestore是前端和后端之间的主要且唯一的连接。当然，某些逻辑可以在前端使用，但是出于安全考虑，通常只能脱机使用户受益。您应该在Cloud Firestore集合本身上实现安全性，确保角色或所需的任何安全。

然后，使用从Cloud Firestore触发器调用的Cloud Functions。

您绝不应该从前端应用程序调用云功能。

— 托德
source