致电…… WorkfromHub
致电…… WorkfromHub
序幕
2021 年初，我们收到了创建应用程序的请求。我不知道这是如何发生的细节。我听说它与人们可以工作的空间有关，并且它们将是可以锁定的东西。
同年 6 月下旬，我被带到了这个项目。
就在这个时候，我发现这些被称为“集线器”，并且它们是自我隔离的、可预订的空间，旨在供用户通过应用程序访问。
我们将提供能够为用户和客户预订、控制访问和提供支付系统的应用程序。
这非常令人兴奋，不是我或我们以前做过的任何事情。虽然我们之前已经构建了网站、应用程序和 Unity 游戏，但与现实世界中的项目的交互是相当新的。
但是等等，对我们来说是新手，我们实际上并不知道这意味着什么。
它需要大量的研究才能到达某个地方，没有很多现成的信息，以至于与客户讨论和他们购买锁以及与供应商讨论如何与锁交互。
这导致我们第一次发现了 API 提供者，并了解了锁，甚至是当你找到它时可用的相当广泛的智能设备领域。
但是，控制和集成它需要一个 API。这是我们需要创造的其他东西。由于我们还需要证明整个集线器概念甚至是可行的，我们还需要创建一个原型。
第1章
“原型”
虽然最终产品将通过移动应用程序发布，但原型是一个 Web 应用程序。
这分为两部分，API 和管理网站，都在 Node.js 上运行。
API 是使用 FeathersJS 编写的。这处理了所用服务的所有抽象，包括第三方锁 API，并使用了 Postgres 数据库。与 Auth0 集成以提供用户身份验证。
“管理员”网站最终还托管了公众最终会使用的网站，因此 API 还提供了基于简单角色系统的一定程度的简单授权。网站呈现的所有内容都是通过调用 API 完成的，因此它可以决定登录用户是否真的有权查看他们请求的资源。
该网站的公共部分允许用户查看枢纽、详细信息、位置，并从那里选择他们想要预订的日期和时间范围并预订插槽。此时，没有与任何支付提供商集成，这必须与客户端手动完成。客户的测试客户数量有限，他们已经安排好了。
原型的主要问题是技术的选择。之所以选择它，主要是因为它在我之前的项目中使用过，并且可以快速轻松地移植它以快速启动和运行 API。但这给正在努力学习它的其他开发人员带来了问题。所以……糟糕的选择。
我们确实发现一些积极的方面是 Auth0 易于集成，并且锁定 API 很好用。我们确实了解到我们的数据库模型存在一些缺点，这始终是一个很好的体验，它仍然有效，但事情可以改进。它让我们对最终版本有了很好的了解。
但总而言之，它让我们相信这会奏效，它让客户相信它是可行的。
第2章
“产品”
一段时间后，原型被使用，发现了一些问题，我们决定我们需要改变和改进什么。
首先要改变？使用 FeathersJS，但是用什么来代替它呢？总的来说，我对使用 Node 和 Typescript 感到非常满意，所以我对此进行了研究。环顾四周，我发现了 NestJS。这对我来说是全新的。控制反转、模块化、“渐进式”框架。
虽然它还提供了托管整个网站的能力，但我对它以非常简单的方式提供 API 更感兴趣。
随着 FeathersJS 的移除，我们还必须决定如何与数据库交互。虽然我可以直接处理 SQL，但我不喜欢编写 SQL。我宁愿选择使用 ORM，而我使用过的一个是 Sequelize。值得庆幸的是，Sequelize 与 NestJS 和 Typescript 配合得很好。
由于对新框架的更改，理解 FeathersJS 变得有点学习曲线，依赖注入并不是我从 Java 时代以来真正做过的事情。很好的是让装饰器处理所有配置，这是我在编写 Unity 和 C# 时已经非常习惯的东西。能够创建装饰器来处理身份验证和授权、处理数据映射以及创建 Swagger 文档非常有用。
网站也改了。它没有成为 API 代码的一部分，而是被移到了一个静态的 React 应用程序中。此外，它只是管理站点。不再有公众访问该网站。它需要管理员用户访问和管理系统中的数据。
此管理站点将提供管理用户、创建位置以及在这些位置创建集线器的能力。管理员可以通过界面将锁分配给集线器，并管理预订的密码。如果管理员愿意，他们可以为用户创建预订，无论是在非工作时间为中心创建，还是以与预订类型不同的价格。界面中的管理员用户有很大的自由度。
同样，我们使用 Auth0 来防止对 Admin 网站和 API 的未经授权的访问，以确保对特权端点的调用也可以访问调用和返回的任何数据。
返回的数据也是有限的，使用类验证器、节点库的集成以及与 NestJS 的集成。连同我编写的装饰器一起，添加到 API 调用中，以确保从 API 返回的值仅包含 DTO 中的数据，以便我们可以显式定义 API 返回的数据。这主要用于公共 API，以防止数据出现在不应该出现的地方。但它也确保返回的 JSON 中的数据是干净的。
在这一切进行的同时，第二位开发人员开始着手开发移动应用程序。这也是一个 Typescript 应用程序，使用 Expo，因为这是一个 Android iOS 多平台应用程序。
开发此功能时的第一个主要问题是我们将所有内容都作为 monorepo 开始，所有内容都在同一个存储库中。这导致部署到目标服务器的问题。至少在当时。决定将其拆分为项目的三个不同部分。虽然我在时间尺度上领先于自己，但我有点希望我们只是将它保留为一个存储库，同时处理三个存储库，当出现错误时，需要在存储库的多个位置进行修复。它会导致噩梦，特别是当只有一个错误跟踪问题时，当部署时间彼此不同时，您必须等待每个完成以确保它“准备好测试”。但这是我们创造的一张床，现在我们必须躺在上面。不，不建议使用 git-submodules，这是一个地狱般的场景（很快就放弃了）。
所以随着发展。两周冲刺，添加功能，添加任务，测试，发现错误，修复错误，与客户会面，展示新的时髦功能，如此循环。
我们使用 Stripe 作为支付提供商集成了 Payments。这是在 Admin 和 Mobile 应用程序中完成的。在我们使用的 Stripe Expo 支付插件版本中发现了一个严重的错误，需要对 Expo SDK 版本进行全面更新，谢天谢地。
我们在早期的数据模型中发现了一些问题，需要将数据移动到不同的地方、数据库重构、添加新数据等。
新系统还开始使用 NestJS 调度程序开始发送电子邮件，使用 Sendgrid。新的调度器还做了一些基本的内务处理，删除了陈旧的、没有删除的、无效的东西。有一个新的要求是添加外部 CRM，预计这需要一段时间，但结果非常容易。
第3章
“尽头快到了”
最后，当时间临近时，我们开始将应用程序发送给 Google 和 Apple 进行审核。
谷歌当然很高兴。
当然，苹果不是。
我们可能忘记了最重要的事情，忽略了我们提交的小图形问题。
用户可以注册，但不能删除他们的帐户。
所以很快我们就想到了如何解决这个问题。我们实际上并不想从系统中删除数据，因为它与所有其他数据相关联。相反，我们必须以不可逆的方式对其进行混淆。
因此，当用户删除其帐户时。它被混淆了。他们的登录详细信息被删除。他们的 Auth0 登录数据被删除。他们所有的私人信息都被打乱了，所以我们无法恢复它们。他们无法登录并恢复它。他们必须创建一个全新的帐户才能再次开始使用该系统。
有了这个，最后的障碍就被越过了让应用程序走出门外。
结语
当然，这还没有结束。还有一些问题我想解决。
总有一些地方是你查看代码并思考的地方，我想修复它，在这里和那里重构它。但我只是一名开发人员，一名问题解决者，我喜欢分析和寻找解决方案，即使人们没有看到问题所在。
我想当我得到，希望，做出那些我确实看到的改变时，会有一个点。
谁知道？
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
