两个 Web 应用程序 - 一个 firebase 项目：我应该为一个应用程序创建两个应用程序还是两个托管站点？答案

【问题标题】：Two web apps - one firebase project: should I create two apps or two hosting sites for a single app?两个 Web 应用程序 - 一个 firebase 项目：我应该为一个应用程序创建两个应用程序还是两个托管站点？
【发布时间】：2020-12-20 18:55:38
【问题描述】：

我正在创建一个 firebase 项目。它包含两个 React Web 应用：一个面向客户端的应用和一个后台应用。
我要么：

在 Firebase 中创建两个具有不同配置的应用和两个托管站点
或在 Firebase 中保留一个应用程序，并在两个 React 应用程序和两个托管站点中使用其配置
据我了解，这些应用可以通过任何一种方式访问相同的资源。

我该怎么办？
更准确地说：在 Firebase 中分离 Web 应用有什么好处？

【问题讨论】：

如果您想这样做，好处是您从将两者分开获得的任何个人便利。你问的是意见问题。
感谢您的评论，但我觉得我没有传达我的问题。我的 Web 应用在我的代码中分离得足够好，并且有不同的托管站点，但我想了解创建两个 Firebase 应用会在哪些方面增加分离度？
如果您不打算在每个应用程序中以不同方式配置 Firebase 产品，那么实际上并没有太大区别。您需要访问特定的用例，并询问单独的应用程序是否有助于或损害该用例。这些用例更有可能围绕 .analytics 而不是开发。
正是我所追求的信息！我找不到有关此功能的任何信息，因为它没有特定名称这一事实没有帮助。如果您碰巧知道一些相关文件，能否分享一下？
另外，如果您将上一条评论设置为答案，我可以接受并关闭问题。

标签： firebase firebase-hosting

【解决方案1】：

如果您不打算在每个应用中以不同方式配置 Firebase 产品，那么实际上并没有太大区别。您需要访问特定的用例，然后询问单独的应用程序是否有助于或损害该用例。单独的应用程序会更有帮助的用例可能围绕分析而不是开发。分析及其相关产品使用应用程序的概念来生成有关该应用程序的有意义的数据，并在这些特定应用程序中创建和定位受众。

【讨论】：

【解决方案2】：

在 Firebase 中分离 Web 应用有什么好处？

在您的情况下，即“面向客户的应用程序和后台应用程序”，您可能具有不同的用户角色：

客户使用面向客户的应用程序（可能具有不同的子角色，例如作者和编辑或团队领导和团队成员，具体取决于您的应用程序的业务范围）
管理员或超级用户，或“后台文员”等...使用后台应用程序。

使用 Firebase 处理这种基于角色的访问控制策略的经典方法是使用 Custom Claims。

除了实现基于角色授予（或不授予）访问权限的方法外，自定义声明还允许您to adapt your app UI depending on the user's role or access level。

这很有趣，但是如果您的应用程序很复杂，并且有多个屏幕（或菜单）根据用户角色具有不同的行为，那么根据变量隐藏/显示部分 UI 很快就会变成一场噩梦。在这种情况下，最好让两个独立的应用（在两个独立的 Firebase 项目中）指向同一个（主）Firebase 项目。

如果不同的开发人员/开发团队在两个应用程序。

【讨论】：

感谢您的详细回答，它增加了有趣的信息。事实上，我计划为客户端和管理员构建两个独立的 React 应用程序，因为它们对于条件渲染到单个应用程序来说太不同了。关于自定义声明，如果我理解正确，用户登录，然后请求他的额外声明，然后请求令牌刷新，因此在此期间状态不完整的 3 次往返，我正确吗？
自定义声明可通过用户的身份验证令牌访问。不需要额外的处理或查找来检查自定义声明和相关的角色/权限。有关详细信息，请参阅here、here 和 here。
由于所有用户帐户在一个项目中的所有应用程序之间共享，因此在一个项目中使用不同的应用程序确实没有很大的优势，就 Firebase Auth 及其自定义声明而言。您可以仅使用单个应用程序实例将用户分成具有自定义声明的许可组。在这方面，使用第二个应用程序只是组织性的 - 如果这是您的偏好，那就用它来运行吧！
感谢您的回答，明天我将探索自定义声明，看看它是否比将声明简单地保留为 firestore 字段有所改进。 Firebase 摇滚！