Firebase 与 Ruby：移动应用开发中的后端哪个更好？

为您的 iOS 或 Android 应用程序选择后端堆栈可能很困难。 这就是为什么在这里我们比较 Firebase 与 Ruby on Rails 编写的后端，并调查是否有任何用于移动应用程序开发的后端技术的“神风选择”。 有什么理由不使用 Firebase 或 Ruby？ 是否可以将 firebase 与 Ruby on Rails 一起使用？ 让我们发现。

如果我说营销是一场争夺人们注意力的竞赛，您是否同意我的观点？ 更重要的是，营销太重要了，不能留给营销部门。 它甚至爬到了与推广无关的利基市场——软件开发； 营销已经成为其中的一部分。 开发人员根据 Github 上一些类似库的星级为他们的项目选择解决方案，以及我们能够预测今年哪些技术将积极增长的帐户“推文”数量。 这种数字环境使我们面临成为炒作受害者的风险，我们可能会在这种情况下被误导 - 只是爱上了由邪恶的营销人员创造的高度推荐的炒作工具。

最近每个人都在谈论的工具之一是 Firebase 及其 API，这是一个由 Firebase, Inc. 于 2011 年开发的移动和 Web 应用程序开发平台，然后在 2014 年被谷歌收购，正如维基百科所说。 在 2014 年 Firebase 被谷歌收购之前，没有证据表明该产品的快速增长，并且一些人声称 Firebase 存在劣势。 尽管从那时起有些事情发生了变化。 Firebase 已在制作应用程序的过程中实施，例如：

• 沙赞
• 阿里巴巴订单和交付应用程序
• Todoist 应用程序管理器

像 Shazam 这样的巨头显然不会进行肆意的预算支出，因此，对他们来说，Firebase 是一个相当合理的选择。 我们试图查看 Firebase 实施的利弊，试图找出它最适合哪个项目。

但是在我们深入了解 Firebase 的优势之前，有两点需要说明 - 消除可能发生的所有可能的误解：

1. Firebase 最初并不打算作为后端选项，该平台的核心是一个数据库。 没有集成服务器部分的奇迹般开发的应用程序并不像。
2. 虽然它不是关系数据库。 Firebase 是一个NoSQL基础，附带所有优点和缺点 + 特定的 Firebase 开发环境和架构。

什么是 NoSQL 数据库？

根据 Basho 的说法，NoSQL（意思是“Not SQL”或“Not Only SQL”）是一种数据库方法，代表了对传统关系数据库管理系统 (RDBMS) 的转变。 要定义 NoSQL，从描述 SQL 开始会很有帮助，SQL 是 RDBMS 使用的一种查询语言。 关系数据库依靠表、列、行或模式来组织和检索数据。 相比之下，NoSQL 数据库不依赖于这些结构，而是使用更灵活的数据模型。 NoSQL 对于存储大量非结构化数据特别有用，其获取速度比结构化数据更快。

相反，结构化查询语言 (SQL) 是数据库架构师用来设计关系数据库的一种编程语言。 在 MySQL、Sybase、Oracle 或 IBM DM2 等 SQL 数据库中，SQL 通过更新、删除或创建新记录来执行查询、检索数据和编辑数据。 SQL 是一种轻量级的声明性语言，它为关系数据库做了很多繁重的工作，就像服务器端脚本的数据库版本一样。
[来源：Upwork]

现在我们已经确定我们在同一页面上，让我们提取使用 Firebase 的一些优势。

1. Firebase 可能更省时。

一旦您开始使用 Firebase 作为后端构建实时应用程序，就不会包含服务器部分开发——因为 NoSQL 不需要它。 因此，从短期来看，这个平台可能需要更少的时间来开发。 一旦您想创建一个简单的应用程序，并为其配备一个小型的无大数据后端，那么 Firebase 就可以快速实施到项目中。 当您有设定的截止日期或即将发生的事件时，Firebase 可能是一个不错的临时解决方案。

2. Firebase 是一个实时解决方案。

如果您需要即时推送通知和更新，那么您需要所谓的实时应用程序。 就 Firebase 而言，有许多代码实验室为它编写 - 其中一些向您展示了如何为不同平台构建聊天应用程序：

• IOS
• 安卓
• 网络

这给了我们一个遵从的理由——Firebase 的所有优点和缺点，它都能满足实时通信应用程序的需求。

3. Firebase 开发是一个非常安全的解决方案。

只要 Firebase 建立在 Google 的基础架构上，就有充分的理由表明它是一个受到良好保护的解决方案。 虽然您可以通过定义 NoSQL 数据库的规则来加倍安全性，因为默认情况下您无法控制存储的数据 - 它托管在 Google 的服务器上。

每朵玫瑰都有刺。

因此，如果您打算让成千上万的人使用您的产品，那么 Firebase 可能是一个毫无价值的解决方案。

一旦您选择 Firebase 作为主要后端堆栈，您需要考虑以下几点。 不是使用 firebase 的缺点，只是你需要知道的事情。 使用 Firebase，您可以自由选择定价方案 - 但适合实时应用程序的方案是“现收现付”方案。 使用此计划，您只需为消耗的资源付费，因此您的应用获得的用户越多 - 后端维护成本就越高。

许多人认为这是一个加分项 - 因为您产品的许多用户都很棒，不是吗？ 但是，一开始很难将所有产品都货币化 - 您首先需要让人们喜欢您的产品。 如果使用 Firebase，您将可以为所有免费用户花钱。 因此，如果您打算让成千上万的人使用您的产品，那么 Firebase 可能是一个毫无价值的解决方案。

有传言说 Firebase 也有隐藏成本，在用户或使用量快速增长之后，您可能会在没有警告的情况下收取费用； 因此，如果您不担心被默默收费 - 那就去做吧。

这就是为什么您的应用程序的另一个不错的后端选项是 Ruby 后端 + 用于数据存储的特​​定服务器（这是我们在处理客户项目时经常使用的方法）。 此外，Ruby on Rails 后端和 Firebase 的优点或多或少相同。 在 Ruby 的情况下，它们如下所示：

1. Ruby 是一种简单的语言。

即使与 PHP 语言及其源代码相比，它也有一个简短的框架列表可以实现，但是有很多 gem - 一个完整的 Ruby 多用途库系统。 同样简单的是语言架构模式 - MVC，具有明确的实体依赖关系。

阅读更多关于架构模式的类型和功能

2. Ruby 社区经受住了时间的考验。

与新成立的 Firebase 开发者协会不同，Ruby 的社区非常庞大，它拥有大量的开源 gem，可以让编码人员快速打开和开发复杂的应用程序。 更重要的是，由于某些 Ruby 的“名气”，许多著名的服务（如 Stripe）都为 Ruby 提供了现成的库。

3. 您可以在 Ruby 上测试您的代码。

Ruby 拥有先进的开发基础设施，允许在整个项目中最大化和编写单元测试 - 以减少新功能和现有功能中的错误。 这也将减少未来在开发过程中更改的成本。

4. 您不依赖于特定类型的数据库。

或者，更准确地说，是特定类型的数据库。 Ruby 允许您使用任何关系型或东方型数据库，以及 NoSQL 和其他不同的技术——包括 Elasticsearch、Reddis 和其他不太流行的技术。

5. Ruby 的语法是小菜一碟。

Ruby 中没有数据类型——并且分别不需要查看数据类型的结构是否适当。 此外，还存在可组合错误系统（也称为日志记录系统）； 这使得搜索错误更容易，然后可以更快地修复发生的错误。

所以，Firebase 与 RoR - 选择哪一个，何时选择？

在 Firebase 与 Rails 比较之后，外交的答案是 - 这主要取决于您的目标。

如果您需要以下其中一项，Firebase 作为移动应用开发的后端非常适合您：

• 具有简单功能的小型实时应用程序
• 一个简单的应用程序，您需要在其中存储负载和负载
• 一款经过概念验证的应用程序，稍后将进行全面翻新

虽然如果您希望创建一个复杂的移动系统，具有令人困惑的算法和功能，Ruby on Rails 移动应用程序后端也是一个不错的选择。 此外，如果应用程序没有清晰的结构，在非关系型数据库中，Firebase 云后端无疑是，您无法从中正确选择数据。 在 Firebase 上创建的业务逻辑通常放在 base 中； 因此，当应用程序逻辑有点混乱时，可能会出现大杂烩。 并且不要忘记，每次获得新用户时都会向您收费，即使您没有通知您 - 您的钱可能只是在您醒来的某个早晨转帐。

希望阅读本文能帮助您了解如何在移动应用程序开发中使用 Firebase - 如果您觉得它符合您的需求。

另请阅读：React Native vs Native App Development - 选择哪一个？

由奥列格·察连科和埃琳娜·贝萨拉波娃撰写