我们生活在令人兴奋的时代。 从设计到开发过程的所有时间，服务不断涌现，比以往任何时候都更快，更便宜地将数字创意转化为现实。 Firebase（以及最近的Firestore）就是其中一种已经存在很长时间的工具，它为您提供了一个完整的后端，即您实际存储和处理用户数据的地方，因此您可以突然减少所需的工作量自己建立和维护此基础架构（更不用说组建一支可以做到这一点的团队了。）
但是，便利总是要付出代价的。 当拥有由外部服务运营的公司的关键基础架构时，您需要了解风险和权衡因素，并在进入之前做好准备。对于Firebase，我建议您为以下情况做准备：
1）对于您的用例而言，其功能集太有限，可能仅在产品的后续迭代中显示
2）您到达了临界点，在该临界点上，您自己的基础架构的运营变得更具成本效益，或者产品达到了不同的成熟阶段，需要以其他方式进行部署（例如，本地企业托管）
3）Google认为从业务角度来说这套产品对他们而言不再有意义，并停止使用它们（就像Facebook在Parse所做的那样）。
这归结为自软件开始以来的事实：一切都会以不可预见的方式发生变化，并且软件工程师的工作是了解其软件将运行的环境，以便他们为更改做准备。
与大多数专业人士一样，程序员必须不断进行基本的权衡：速度还是质量？ 特别是对于软件，有两个主要的危险：没有足够的远见，以及为太多永远不会发生的场景做准备。 幸运的是，由于Web开发相对简单，因此有一些基本的体系结构准则，无需过多的工作即可显着降低风险。
本文的技术性部分将基于一个基本规则：良好的体系结构可将重要的决定推迟到最后的负责任时刻。 在此过程中，我们将意外发现此规则的某些后果，这些后果使我们能够：
- 只需很少的工作即可生成质量更高的代码
- 测试变更更快，使开发更有趣
- 在团队中更轻松地分配任务
- 提高短期和长期代码质量
- 大大降低意外破坏东西和愤怒小怪敲门的风险。
警告：下一部分仅供技术人员使用。 不属于这个人群吗？ 您可以跳过下一部分而不会感到内gui。 我承诺。 也许🙂
拖延！ 谁不喜欢它？ 好吧，这次我们可以实际使用它来发挥我们的优势。 当我们开始开发新产品并与我们的用户进行测试时，我们真的需要马上使用后端吗？ 在很多情况下，我们却没有这样做，如果您在一家设计驱动的公司工作，则应优先考虑尽快将可测试的内容交到用户手中。
因此，为什么不首先在我们的代码中直接使用Firebase，为什么不首先创建一个包含UI可能需要的所有内容的后端类？ 作为第一步（使用诸如Airbnb之类的允许用户进行交流的应用程序），我建议使用非常具体的方法来实现一个类，例如`backend.privateMessaging.getConversationsForUser（）`返回一些包装好的静态虚拟数据当然，在Promises中，您可以查看UI是否与假设的后端进行交互。 使用TypeScript，您可以开始生成一些初步的文档，说明产品中流过的数据结构类型。
到现在为止，您应该已经有了人们可以点击的内容，并且可以在团队中共享，以找出最明显的摩擦点。 下一步，您实际上可以实现一些逻辑，以便我们可以测试事物如何随着变化而工作。 我们需要一个真正的后端吗？ 没呢还没。 您现在只能将数据保存在内存中，但目前我最喜欢的是将Dexie与内存中的IndexedDB后端一起使用。 这样，您可以选择在本地保留更改，或者忘记所有操作。 这样做的好处是，您现在已经可以开始为后端类编写自动化测试了，因此一旦开始集成实际的后端，您就已经具有测试其实际行为所必需的测试。 另外，运行带有内存后端的自动化测试将为您带来不错的速度提升，因此您可以轻松地将整个套件保持在500ms以下。
您是否已与您的用户测试过？ 如果是这样，这就是开始考虑后端的正确时机。 有了自动化测试并很好地了解了UI与后端之间的交互方式，我们将可以更轻松地在后端设计数据模型。 在这里，您可以决定Firebase是否适合您，或者是否要使用PostgreSQL / Mongo / Redis / whatever-floats-your-boat实现自己的REST / GraphQL后端。 您的用户界面无关紧要，由于有了自动化测试，您可以安全地实现所需的任何后端，尤其是在切换/重新构造后端的时候。
使用上面的简单技巧，我们可以在正确的时间做出正确的决定。 我们一直等到后端的实际实现，直到我们知道初始产品已经完成并已通过用户测试。 一路上，您会注意到：
- 从头开始，您的团队节省了在后端上工作的时间，因此他们可以快速实现UX / UI要求。
- 您对UX / UI的更改可以更快地进入设计人员的手中，以提供反馈和请求更改，这可能会影响后端的要求，然后再实施。
- 结合使用内存后端和其他一些技巧（不在本文的讨论范围内），您可以轻松地直接跳至某些预定义的方案，例如，用户租用了3套公寓，获得了2条评论。 这样，您可以轻松地在团队中分配工作，更轻松地重现错误以及演示这些特定方案。
- 通过将后端的架构延迟到最后一个可能的时刻，可以避免在启动产品的第一次迭代之前做出必须重写的决定。
- 编写自动化测试变得更加容易，从而提高了代码质量，易于实现（和切换）不同的后端，并在持续部署过程中更具信心。
- 使用这些UI的人员可以使用这些自动化测试对后端团队提出非常具体的要求，从而改善内部沟通。
结论？ 与知道如何设计程序并代表质量，灵活性和速度的优秀工程师一起工作，因为他们知道它们如何影响整个组织以及最终他们的用户的生活质量。 结果，您可以节省成本，变得更加敏捷，并可以更有效地发现/满足用户的需求。
我想与您分享两种可能性：
- 开发人员可以通过关注GitHub上的Storex并为之贡献力量，从而开始简化数据管理。 注意您必须两次实现后端类吗？ 尽管以上述方式编写代码已经可以极大地改善您的工作流程，但我们可以做得更好。 我们与WorldBrain一起，开始开发一个称为Storex的NPM软件包生态系统，让您以与后端无关的方式描述数据，使您可以一次编写后端/存储逻辑并轻松切换出实际的后端，同时解决了许多问题。常见问题，例如全文搜索，客户端-服务器通信，架构迁移，提供者迁移和实时通信。
- 团队和经理，请与我们联系，以变得更加出色。 想要成为一个真正的以设计为中心的组织吗？ 我们可以帮助您从设计思维到改善开发流程和内部沟通的整个过程。 无论您是在扩展自己的价值主张还是在开发全新产品，请将消息发送至hello@youapt.eu，以便我们确定如何为您提供最佳帮助。
喜欢这篇文章吗？ 如果您可以按住鼓掌按钮并按住20至50个鼓掌，我们将不胜感激，这样我们可以获得更多的曝光机会，并且有更多的可能性为您制作有用的内容。
