从这里开始，我们为每个前端减少了 1 个技术！
Serverless数据库时代
目前，围绕数据库作为服务（DaaS）的解决方案或者说后端作为服务（BaaS）正在兴起 。BaaS的目标是提供应用程序所需的所有功能，以便你无需在后端编写一行代码 。你只需要在你的BFF中编写查询，就完成了 。
最著名的BaaS无疑是Firebase ， 它提供了许多功能，如实时文档数据库、身份验证服务、数据库之上的权限机制、文件系统存储等等 。
然而，Firebase也有一些严重的限制：
Firebase 数据库，无论是 Realtime 数据库还是 Firestore，都是单模型数据库（文档数据库） 。
它只能作为一个单向图进行遍历（如果我们可以将其视为图的话） 。
还有另一个叫做Supabase的著名BaaS，试图与Firebase相媲美 。使用类似PostgreSQL的关系型数据库消除了Firebase的一些限制 ， 但它仍然是单模型数据库...
最近引起我注意的一个项目是SurrealDB 。它是一个带有内置后端的数据库，具有许多许多功能（我觉得“许多”这个词写得还不够） 。作为一个真正的多模型数据库，并且有一种新的查询语言 ， 他们能够提供应该让你写一些代码的功能 。
最近，这种类型的数据库被越来越广泛地称为元数据库 。
文章插图
完全单体架构
N = META-FRAMEWORK + META-DATABASE
从那里开始，我们在另一个层面上大大减少了技术数量 。
附加内容：利用单一仓库架构
与微服务一样，编写单体应用意味着拥有正确的工具箱 。这个工具箱可以解决我们通常遇到的约束，比如：
太庞大以至于无法失败，一个简单的错误可能会导致整个服务崩溃 。
长时间部署，编译大型项目通常需要很长时间 。
无法跨团队隔离和共享的单一代码库 。
使用这种架构，对纯净和全面的单体架构（前端 + 后端）的需求就不再存在 。然而，元框架是超过 80% 的代码将驻留的部分 。为此，现在有一些工具可以使用 ， 例如 turborepo 。
我们还没有提到的一个不可避免的需求是数据库脚本迁移 。当然，这些脚本需要存储在单独的仓库中，没有什么复杂的 。
【Serverless单体架构的崛起】
推荐阅读
- Redis中Leader-Follower架构如何确保数据一致性和可靠性？
- 微服务架构中的数据一致性
- 九个问答牢记RocketMQ架构
- 基于Go-Kit的Golang整洁架构实践
- 听说你会架构设计？
- 聊聊微服务链路服务
- Eureka: 微服务架构中不可或缺的服务治理工具
- 云原生数据库 GaiaDB 架构设计解析：高性能、多级高可用
- 现代软件架构：事件驱动设计遇上事件溯源
- 从MySQL看主从架构高可用性实现