为什么我选择 Strapi、Flutter 和 React 为多租户 SaaS 构建 MVP
在这篇文章中,我将介绍我的销售团队如何在为我们正在构建的这个 SaaS 平台决定(/透视)技术堆栈方面发挥了至关重要的作用。当我们的设计团队仍在开发 UI 时,营销人员设法将产品销售给了两个客户。现在我们必须在短时间内达到 MVP(Minimum Viable Product)点,才能让客户留下来。
我们要做的第一件事就是找到一个精简版的 MVP。所以我们不得不从之前决定的列表中删除很多功能。它并没有就此停止。我们还必须说服设计团队给我们一个非常简单的 UI 来加快开发速度。
决定技术栈的因素
我们,开发人员,通过考虑多个变量来选择构建项目的技术,例如
-
项目要求。
-
资源可用性。
-
上市时间。
-
开发和维护成本。
-
可扩展性。
-
安全。
我们在建造什么?
我不能给你平台的背景。我的组织不允许我这样做。因此,为了这篇博文,我们假设我们正在构建的系统是针对小公司的应用程序。该平台旨在提供统一版本的CRM和ERP。此外,我们的目标是多家类似公司成为我们的潜在客户。这就是多租户发挥作用的地方。
平台利益相关者
1、管理人员。
-
初级职员。
-
客户。
这导致我们的系统具有针对不同用户角色的多个身份验证和授权流程。此外,由于不同的角色具有不同级别的权限,因此需要数据安全策略。 (低级别员工将无权访问客户数据)。
部署
-
所有经理都将拥有一个网络应用来与客户沟通并委派初级员工。
-
初级员工将使用移动应用来接收经理的任务。
-
客户在手机应用的帮助下,可以下订单和付款,偶尔也可以与经理交谈,以防万一发生任何意外或其他需要。
最终技术栈
凭借雄心勃勃的上市时间(或这种情况下的 MVP),从头开始构建这个具有完整功能的多租户、多用户系统是不可想象的。
后端
实际的选择是从无头 CMS 开始。Strapi是一个简单的决定,因为它几乎拥有系统要求或我喜欢的一切。
-
多个用户角色。
-
基于角色的权限。 (与isOwner政策)
-
支持MongoDB。
-
GraphQL 支持。
-
深度查询(开箱即用🤯)。
其他一些福利包括
-
直观的管理仪表板。
-
友好的社区。
-
开发人员友好的文档。
对于支付,我们采用了微服务方法。支付服务是用 NodeJS 编写的,并有一个 PostgreSQL 数据存储用于持久性。
为了实现多租户,我使用的方法是在所有表(或集合)中添加一个 organization_id 列(或字段)。从而消除来自应用层中另一个组织的请求。

网页应用
由于经理是 Web 应用程序 的唯一用户,而且他们只会在办公室使用它,这给我们带来了一些优势。
-
高速、高正常运行时间的办公互联网 - 所以我们不必担心 PWA 和离线支持。
-
台式机/平板电脑用户 - 无需支持移动设备。
考虑到这一切,我们决定使用 ReactJS (CRA) 构建一个单页应用程序 (SPA)。为了加快开发速度,我们决定进一步使用用于 React 的Material-UI库。通过选择这条路,我们必须牺牲我们设计团队已经工作了数周的 UI。
手机App
Flutter是首选框架,因为我们之前构建了一个Flutter 应用程序,现在它已投入生产。所以我用它制作了一个入门工具包,从而为我们提供了一个先机。该套件包括
- 多个可重复使用的小部件。
2.状态管理。 (提供者)
3.缓存在设备中(HiveDB)
和很多样板代码。
经过所有这些努力,MVP 现在终于准备就绪,明天将进行第一个客户端演示。祝我们好运🥳。
更多推荐
所有评论(0)