全栈改变了什么 全栈开发的概念已经存在多年,但自 2022 年以来它的流行度急剧上升。因此,它的含义也发生了变化。 本来全栈开发是指前端和后端技术都精通的人。这只是一个人的两个角色,因为技术和技能都不相同。前端开发人员大多使用 HTML/CSS/Javascript 并构建精美的 UI,而后端开发人员使用 PHP/Java/C# 来实现服务器端业务逻辑。 与人类历史上的许多其他情况一样,工具通常是革命性变革的主要驱动力。让我们看一下该领域的一些具有代表性的工具。TypeScript 感谢 TypeScript,我认为这是历史上第一次前端和后端开发人员能够并且愿意使用相同的编程语言来工作。你可能会争辩说 JavaScript 在 2009 年 Node.js 发布时已经实现了这一点。但我听说很多后端开发人员从 Java 或 C# 等强类型语言转过来,包括我自己;我们肯定不愿意使用Javascript。正如 Typescript 的核心开发人员 Hejlsberge 在最近的采访中指出的那样,主要原因是: 他们根本无法扩展到大型 JavaScript 应用程序 原因是:JavaScript 中没有面向对象的编程。没有类型系统,你就不可能在代码中指定你的意图,这使得维护变得非常困难。没有类型系统,就很难构建工具。Next.js 感谢 Next.js,它允许您在同一框架中编写前端和后端代码。使用像 getServerSideProps 这样的函数,你实际上将前端和后端代码写在同一个文件中: 或者,使用新引入的服务器组件,您实际上在同一个函数中编写前端和后端代码: 由于它允许您在一个框架中编写整个 Web 应用程序带来的便利,它确实带来了一些负担,因为有时您可能会想:等一下,这段代码是在服务器中运行还是在浏览器中运行?tRPC 多亏了 tRPC,它允许你忘记网络边界,像调用具有端到端类型安全的本地函数一样调用远程函数: "转到定义"和"重命名"也可以跨网络边界使用。所以有时候你真的忘记了你实际上是在调用远程过程。 通过与 Zod 的集成,后端验证已得到处理。通过围绕React Query 的包装器,缓存也得到了处理。因此,除了前端工作之外,您唯一需要做的就是定义和实现路由器功能。 看看google趋势,2022年左右你会看到和full-stack一样的leap time。 我打赌你知道那个时期出现的其他工具改变了全栈开发的思维方式。因此,正如著名的"忒修斯之船"悖论: 如果一艘船的所有部件都随着时间的推移被更换,它仍然是同一艘船还是一艘新船 我会认为它是一个新的,因为你可以看到越来越多的人没有传统的后端技术和技能,也可以构建一个完整的网络应用程序,这在以前是不可能的。 那么将新的全栈称为ZenStack怎么样?将其视为全栈的 Zen 模式,让您专注于构建重要的东西——用户体验,而不是像安全、可靠、可扩展的东西那样的可用性。 后端复杂性去了哪里? 虽然现在专注于用户体验很棒,但事情不能简单地消失,那么后端的复杂性去哪儿了? 让我们看一下后端的一些典型任务设计和实现数据库模式 这通常是后端开发人员的首要任务。这以前涉及创建数据库表,定义表之间的关系,在代码中定义相应的实体类等。此外,您还需要处理架构迁移,这既有风险又频繁。需要对数据库有很好的了解和 SQL 语言。 感谢 Prisma,上述所有任务都被简化为一个直观的数据模型,如下所示:model User { id Int @id @default(autoincrement()) createdAt DateTime @default(now()) email String @unique name String? role Role @default(USER) posts Post[] } model Post { id Int @id @default(autoincrement()) createdAt DateTime @default(now()) updatedAt DateTime @updatedAt published Boolean @default(false) title String @db.VarChar(255) author User? @relation(fields: [authorId], references: [id]) authorId Int? } enum Role { USER ADMIN } 您可以使用类型安全、自动完成的查询构建器和自动迁移来自动生成 Typescript 类型。开发API 无论是使用 RESTful 还是 GraphQL,通常都需要花费大量时间来设计和实现一组可用于对数据库中的数据执行 CRUD(创建、读取、更新、删除)操作的端点。 感谢 tRPC,正如您已经看到的,您几乎可以通过仅定义 tRPC 路由器来忘记这部分。实际上,通过使用 prisma-trpc-generator,您甚至不需要定义路由器。它可以直接从 Prisma 数据模型生成它。实现用户认证和授权 身份验证曾经是一个非常具有挑战性的部分,因为现代应用程序通常倾向于基于 OAuth 的身份验证,它将身份验证委托给受信任的第 3 方。解释 OAuth 的工作原理是我最喜欢的面试问题之一,但很少有受访者能够很好地解释它。 感谢 NextAuth,它提供了一个出色的解决方案来引入安全的复杂性,而无需自己构建它的麻烦。它附带了一个广泛的提供者列表,可以快速添加 OAuth 身份验证,并为许多数据库和 ORM(包括 Prisma)提供适配器。 授权基于身份验证。它控制"谁可以对哪些资产采取什么行动"。所以本质上,它与访问控制是一样的。它甚至更加复杂,即使是经验丰富的开发人员也很难做到正确。不仅因为您需要对不同的访问控制模型有很好的理解,例如基于角色的访问控制(RBAC)、基于属性的访问控制(ABAC)和自主访问控制(DAC),而且还具有出色的架构由于逻辑分散在代码库中,因此能够使其清晰和可扩展。 ZenStack来了,但这次是我们目前正在构建的工具包。遵循让您专注于构建重要事物的愿景,我们的主要目标之一是为您减轻访问控制的痛点。我们很幸运能够站在巨人的肩膀上。ZenStack 建立在 Prisma 之上,还与 tPRC 和 NextAuth 集成。因此,通过采用它,您可以获得上述这些工具提供的所有好处,以及模型中定义的声明性访问策略: 业务逻辑 这是大部分工作,对每个企业来说都是真正重要的。尽管如此,现在它已经变得容易得多,因为许多通用的工作已经被抽象掉了。越来越多的 SaaS 公司为支付、电子邮件、客户服务、CMS、CRM、电子商务等垂直功能提供开箱即用的解决方案。您需要做的就是与他们集成。 但是,没有与这些第 3 方集成的标准。您需要仔细阅读每一个的文档、API 和 SDK,并将其集成到您的系统中。在我看来,这不仅耗时,而且如果操作不当,还会使整个系统变得不稳定。您是否也将此视为您的痛点?您是否希望以一种标准且集中的方式将这些第 3 方模型视为您自己模型的一部分,例如:// nextauth model Account { id String @id @default(cuid()) userId String type String provider String providerAccountId String refresh_token String? // @db.Text access_token String? // @db.Text expires_at Int? token_type String? scope String? id_token String? // @db.Text session_state String? user User @relation(fields: [userId], references: [id], onDelete: Cascade) @@unique([provider, providerAccountId]) } // paypal model Payment { id Int @id @default(autoincrement()) orderID String status String } // shopify model Order{ id Int @id billing_address Address cart_token String checkout_token String client_details ClientDetail current_total_price Int } 如果这是你所需要的,或者你有任何其他痛点希望可以解决,欢迎加入我们。让我们一起做一个更好的ZenStack。 ============================================================== 这个项目还是蛮有想法的,有点意思,虽然目前在GitHub上星标还不太多。我看好她!