尧图网页设计 
Wasp 框架的愿景设计从声明式 DSL 到规格驱动的声明式架构【免费下载链接】waspThe batteries-included full-stack framework for the AI era. Develop JS/TS web apps (React, Node.js, and Prisma) using declarative code that abstracts away complex full-stack features like auth, background jobs, RPC, email sending, end-to-end type safety, single-command deployment, and more.项目地址: https://gitcode.com/GitHub_Trending/wa/wasp本文以 Wasp 仓库中 v0.12 版本文档 vision.md 为主体逐条拆解官方对 Wasp 的设计愿景——把 Web 应用开发变成“写规格说明书”、以声明式语言作为统一 React / Node.js / Prisma 的“胶水代码”、实体Entity作为一等公民、开箱即用的 CRUD、智能操作、逃逸机制与极简部署——并结合同仓库内的语言定义、示例项目与部署配置印证每条愿景在当前实现中的落点。读完本篇你能理解 Wasp 为什么选择“规格/语言优先”而非“库优先”的架构路线以及这套理念如何在真实代码中兑现。一、核心理念编程应该像写规格文档愿景文档开篇给出了 Wasp 的根本目标见 vision.mdWith Wasp, we want to make developing web apps easy and enjoyable, for novices and experts in web development alike. Ideal we are striving for is that programming in Wasp feels like describing an app using a human language - like writing a specification document where you describe primarily your requirements and as little implementation details as possible.翻译过来是Wasp 希望让 Web 应用开发对新手和专家都变得简单且愉快理想状态是在 Wasp 中编程的感觉像“用人类语言描述一个应用”——更接近于写一份规格说明书你主要描述需求尽量少描述实现细节。创建一个新的、生产可用的 Web 应用应当是容易的把它部署到生产环境应当是直接的straightforward。这一理念在文档站 introduction 中有呼应main.wasp是应用的中心文件开发者在其中从高层描述整个应用而底层的“秘方”是 Wasp 编译器——它读取 Wasp 配置和你的 JavaScript/TypeScript 代码输出客户端应用、服务端应用与部署代码。因为编译器“理解”你的代码所以它可以代劳认证 UI、全栈类型安全、邮件发送、异步 Job、数据获取等大量样板工作并且随框架版本升级自动维护这些生成的代码。二、为什么是“语言/规格”而不是“库”胶水代码哲学v0.12 版愿景文档中最关键的架构论断是vision.md#L10-L13That is why we believe Wasp needs to be a programming language (DSL) and not a library - we want to capture all parts of the web app into one integrated system that is perfectly tailored just for that purpose. On the other hand, we believe that trying to capture every single detail in one language would not be reasonable.即Wasp 必须是一门编程语言DSL而非一个库——它要把 Web 应用的所有部分捕获进一个为这个目的量身定制的集成系统。但官方同时承认试图用一种语言捕获每一个细节是不合理的React 之于组件、CSS/HTML 之于样式标记、JS/TS 之于逻辑这些方案在各自领域已经非常成熟Wasp 不打算替换它们。Wasp 把自己定位为声明式的“胶水代码”declarative glue code把这些专用方案统一起来在它们之上提供“Web 应用”这一更高层的抽象。这种“不做全能语言只做上层粘合”的取舍正是后来被称为“横向语言”horizontal language的由来。v0.12 时代的实现载体是.wasp文件中的声明式 DSL其形态在 Wasp Language 文档 中有完整定义语言是声明式、静态类型的 DSL语法上更接近 JSON、CSS 或 SQL而不是 JavaScript 或 Python——它是配置语言不是通用编程语言代码的核心是声明declaration形如declaration_type declaration_name declaration_body例如app MyApp { title: My app } route RootRoute { path: /, to: DashboardPage } page DashboardPage { component: import { DashboardPage } from src/Dashboard.jsx }类型系统分为基本类型string、bool、number、dict、list、tuple以及ExtImport外部导入、pslPrisma Schema Language 代码块等与领域类型app、entity、query、action、page、route、api、job、crud等声明类型及DbSystem、HttpMethod、EmailProvider等枚举后者正是建模 Web 应用概念的部分也是“领域类型让 Wasp 变得特别”的原因。值得注意的历史演进当前仓库中的最新版文档 web/docs/vision.md 已将同一愿景更新为“Wasp 需要是一个spec-driven framework规格驱动的框架而非仅仅是库”愿景清单的第一条也从“Declarative, static language”改为“Declarative, statically typed spec”声明式、静态类型的规格。从 v0.12 的.waspDSL 到当前仓库中的 TypeScript 规格TS Spec这条“语言/规格优先”的主线从未改变改变的只是承载形式。三、愿景清单逐条印证十条设想在仓库中的落点v0.12 愿景文档列出了十条具体设想vision.md#L18-L30。下面逐条对照仓库中的实现证据。3.1 声明式、静态的“横向语言”支持多文件与库Declarative, static languagewith simple basic rules andthat understands a lot of web app concepts- horizontal language. Supports multiple files/modules, libraries.这一条直接对应 general/language.md 中对 Wasp 语言的定义简单的基本规则、静态类型检查如把app声明体的title字段写成little会直接触发 Wasp 编译器的类型错误、多模块/多文件支持。当前仓库中这一愿景进一步落地为 TypeScript 规格示例项目 examples/kitchen-sink/main.wasp.ts 展示了规格如何按功能拆分为多个模块文件——auth.wasp、crud.wasp、db.wasp、jobs.wasp、apis.wasp、chat.wasp等各自独立再由 app 声明 汇总export default app({ name: KitchenSink, wasp: { version: 0.26.0 }, title: Wasp Kitchen Sink, webSocket, auth: authConfig, server: { setupFn: serverSetup, middlewareConfigFn: serverMiddlewareFn, envValidationSchema: serverEnvValidationSchema, }, client: { rootComponent: App, setupFn: clientSetup, envValidationSchema: clientEnvValidationSchema, }, db, emailSender: { provider: SMTP, defaultFrom: { email: kitchen-sinkwasp.sh } }, spec: [route(HomeRoute, /, page(HomePage), { prerender: true }), authSpec, operationsSpec, jobsSpec, ...], });“横向语言”在这里体现得非常直白路由、认证、Job、API、数据库、WebSocket、邮件发送全部是同一种规格里的平级声明而不是散落在多个框架的配置里。3.2 与主流技术无缝集成内联或外部文件Integrates seamlessly with the most popular technologiesfor building specific, more complex parts of the web app (React, CSS, JS, ...). They can be used inline (mixed with Wasp code) or provided via external files.“胶水代码”定位的具体化Wasp 不替代 React/CSS/JS而是集成它们。证据在规格语言本身的类型系统中——ExtImport类型允许在声明体内直接写import { DashboardPage } from src/Dashboard.jsx路径以src开头相对src目录解析即“内联”方式同时 project/customizing-app.md 展示了client、server、head等字段如何引用外部组件与脚本。示例项目里 React 页面、CSS 框架、JS/TS 逻辑代码全部原样保留在src/目录中Wasp 只在main.wasp或现在的main.wasp.ts一层把它们组织起来。3.3 逃逸机制Hatches在正确的地方定制平时保持隐藏Has hatches (escape mechanisms) that allow you to customize your web appin all the right places, but remain hidden until you need them.这是 Wasp 设计中非常实用的一条。v0.12 文档中两处典型 hatch服务端project/server-config.mdserver.setupFn声明一个在服务启动时执行的函数可直接拿到 Express 的app实例挂自定义路由server.middlewareConfigFn用于定制中间件// src/myServerSetupCode.ts import { ServerSetupFn } from wasp/server import { Application } from express export const mySetupFunction: ServerSetupFn async ({ app }) { app.get(/customRoute, (_req, res) { res.send(I am a custom route) }) }客户端project/client-config.mdclient.setupFn提供等价的客户端启动钩子。这些字段不配置时完全不存在配置后又能直通底层框架——正是“平时隐藏、需要时打开”的 hatch 形态。当前仓库的 kitchen-sink 示例中server.setupFn/client.setupFn仍是同一机制说明这一设计从 v0.12 起是稳定的。3.4 Entity数据模型是一等公民Entity (data model) is a first-class citizen- defined via custom Wasp syntax and it integrates very closely with the rest of the features, serving as one of the central concepts around which everything is built.v0.12 中实体用自定义 Wasp 语法内嵌 PSL 代码块定义见>entity Task {psl id Int id default(autoincrement()) description String isDone Boolean psl}底层由 Prisma 承载psl即 Prisma Schema Language。各示例项目中的 schema.prisma 与 migrations 目录印证了这条链路Wasp 实体声明 → Prisma 数据模型 → SQL 迁移。3.5 开箱即用的 CRUD一条声明生成整套后端逻辑Out of the boxsupport for CRUD UI based on the Entities, to get you quickly going, but also customizable to some level.这条愿景在 v0.12 时代已经以Automatic CRUD功能落地data-model/crud.md一条crud声明就能让 Wasp 自动为实体生成创建、读取、更新、删除的服务端逻辑Queries 和 Actions并随实体定义的变化自动重新生成crud Tasks { entity: Task, operations: { getAll: { isPublic: true, // by default only logged in users can perform operations }, get: {}, create: { overrideFn: import { createTask } from src/tasks.js, }, update: {}, }, }其中getAll、get、update用默认实现create指定了自定义实现overrideFn正是 hatch 思想的体现默认能力开箱即用需要时逐操作覆盖且每个操作可独立控制公开/私有权限。3.6 “智能”操作Queries 与 Actions尽量消除客户端-服务端的心智负担Smart operations (queries and actions)that in most cases automatically figure out when to update, and if not it is easy to define custom logic to compensate for that. User worries about client-server gap as little as possible.v0.12 文档 contenteditable="false">【免费下载链接】waspThe batteries-included full-stack framework for the AI era. Develop JS/TS web apps (React, Node.js, and Prisma) using declarative code that abstracts away complex full-stack features like auth, background jobs, RPC, email sending, end-to-end type safety, single-command deployment, and more.项目地址: https://gitcode.com/GitHub_Trending/wa/wasp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Wasp 框架的愿景设计：从声明式 DSL 到规格驱动的声明式架构
Wasp 框架的愿景设计从声明式 DSL 到规格驱动的声明式架构【免费下载链接】waspThe batteries-included full-stack framework for the AI era. Develop JS/TS web apps (React, Node.js, and Prisma) using declarative code that abstracts away complex full-stack features like auth, background jobs, RPC, email sending, end-to-end type safety, single-command deployment, and more.项目地址: https://gitcode.com/GitHub_Trending/wa/wasp本文以 Wasp 仓库中 v0.12 版本文档 vision.md 为主体逐条拆解官方对 Wasp 的设计愿景——把 Web 应用开发变成“写规格说明书”、以声明式语言作为统一 React / Node.js / Prisma 的“胶水代码”、实体Entity作为一等公民、开箱即用的 CRUD、智能操作、逃逸机制与极简部署——并结合同仓库内的语言定义、示例项目与部署配置印证每条愿景在当前实现中的落点。读完本篇你能理解 Wasp 为什么选择“规格/语言优先”而非“库优先”的架构路线以及这套理念如何在真实代码中兑现。一、核心理念编程应该像写规格文档愿景文档开篇给出了 Wasp 的根本目标见 vision.mdWith Wasp, we want to make developing web apps easy and enjoyable, for novices and experts in web development alike. Ideal we are striving for is that programming in Wasp feels like describing an app using a human language - like writing a specification document where you describe primarily your requirements and as little implementation details as possible.翻译过来是Wasp 希望让 Web 应用开发对新手和专家都变得简单且愉快理想状态是在 Wasp 中编程的感觉像“用人类语言描述一个应用”——更接近于写一份规格说明书你主要描述需求尽量少描述实现细节。创建一个新的、生产可用的 Web 应用应当是容易的把它部署到生产环境应当是直接的straightforward。这一理念在文档站 introduction 中有呼应main.wasp是应用的中心文件开发者在其中从高层描述整个应用而底层的“秘方”是 Wasp 编译器——它读取 Wasp 配置和你的 JavaScript/TypeScript 代码输出客户端应用、服务端应用与部署代码。因为编译器“理解”你的代码所以它可以代劳认证 UI、全栈类型安全、邮件发送、异步 Job、数据获取等大量样板工作并且随框架版本升级自动维护这些生成的代码。二、为什么是“语言/规格”而不是“库”胶水代码哲学v0.12 版愿景文档中最关键的架构论断是vision.md#L10-L13That is why we believe Wasp needs to be a programming language (DSL) and not a library - we want to capture all parts of the web app into one integrated system that is perfectly tailored just for that purpose. On the other hand, we believe that trying to capture every single detail in one language would not be reasonable.即Wasp 必须是一门编程语言DSL而非一个库——它要把 Web 应用的所有部分捕获进一个为这个目的量身定制的集成系统。但官方同时承认试图用一种语言捕获每一个细节是不合理的React 之于组件、CSS/HTML 之于样式标记、JS/TS 之于逻辑这些方案在各自领域已经非常成熟Wasp 不打算替换它们。Wasp 把自己定位为声明式的“胶水代码”declarative glue code把这些专用方案统一起来在它们之上提供“Web 应用”这一更高层的抽象。这种“不做全能语言只做上层粘合”的取舍正是后来被称为“横向语言”horizontal language的由来。v0.12 时代的实现载体是.wasp文件中的声明式 DSL其形态在 Wasp Language 文档 中有完整定义语言是声明式、静态类型的 DSL语法上更接近 JSON、CSS 或 SQL而不是 JavaScript 或 Python——它是配置语言不是通用编程语言代码的核心是声明declaration形如declaration_type declaration_name declaration_body例如app MyApp { title: My app } route RootRoute { path: /, to: DashboardPage } page DashboardPage { component: import { DashboardPage } from src/Dashboard.jsx }类型系统分为基本类型string、bool、number、dict、list、tuple以及ExtImport外部导入、pslPrisma Schema Language 代码块等与领域类型app、entity、query、action、page、route、api、job、crud等声明类型及DbSystem、HttpMethod、EmailProvider等枚举后者正是建模 Web 应用概念的部分也是“领域类型让 Wasp 变得特别”的原因。值得注意的历史演进当前仓库中的最新版文档 web/docs/vision.md 已将同一愿景更新为“Wasp 需要是一个spec-driven framework规格驱动的框架而非仅仅是库”愿景清单的第一条也从“Declarative, static language”改为“Declarative, statically typed spec”声明式、静态类型的规格。从 v0.12 的.waspDSL 到当前仓库中的 TypeScript 规格TS Spec这条“语言/规格优先”的主线从未改变改变的只是承载形式。三、愿景清单逐条印证十条设想在仓库中的落点v0.12 愿景文档列出了十条具体设想vision.md#L18-L30。下面逐条对照仓库中的实现证据。3.1 声明式、静态的“横向语言”支持多文件与库Declarative, static languagewith simple basic rules andthat understands a lot of web app concepts- horizontal language. Supports multiple files/modules, libraries.这一条直接对应 general/language.md 中对 Wasp 语言的定义简单的基本规则、静态类型检查如把app声明体的title字段写成little会直接触发 Wasp 编译器的类型错误、多模块/多文件支持。当前仓库中这一愿景进一步落地为 TypeScript 规格示例项目 examples/kitchen-sink/main.wasp.ts 展示了规格如何按功能拆分为多个模块文件——auth.wasp、crud.wasp、db.wasp、jobs.wasp、apis.wasp、chat.wasp等各自独立再由 app 声明 汇总export default app({ name: KitchenSink, wasp: { version: 0.26.0 }, title: Wasp Kitchen Sink, webSocket, auth: authConfig, server: { setupFn: serverSetup, middlewareConfigFn: serverMiddlewareFn, envValidationSchema: serverEnvValidationSchema, }, client: { rootComponent: App, setupFn: clientSetup, envValidationSchema: clientEnvValidationSchema, }, db, emailSender: { provider: SMTP, defaultFrom: { email: kitchen-sinkwasp.sh } }, spec: [route(HomeRoute, /, page(HomePage), { prerender: true }), authSpec, operationsSpec, jobsSpec, ...], });“横向语言”在这里体现得非常直白路由、认证、Job、API、数据库、WebSocket、邮件发送全部是同一种规格里的平级声明而不是散落在多个框架的配置里。3.2 与主流技术无缝集成内联或外部文件Integrates seamlessly with the most popular technologiesfor building specific, more complex parts of the web app (React, CSS, JS, ...). They can be used inline (mixed with Wasp code) or provided via external files.“胶水代码”定位的具体化Wasp 不替代 React/CSS/JS而是集成它们。证据在规格语言本身的类型系统中——ExtImport类型允许在声明体内直接写import { DashboardPage } from src/Dashboard.jsx路径以src开头相对src目录解析即“内联”方式同时 project/customizing-app.md 展示了client、server、head等字段如何引用外部组件与脚本。示例项目里 React 页面、CSS 框架、JS/TS 逻辑代码全部原样保留在src/目录中Wasp 只在main.wasp或现在的main.wasp.ts一层把它们组织起来。3.3 逃逸机制Hatches在正确的地方定制平时保持隐藏Has hatches (escape mechanisms) that allow you to customize your web appin all the right places, but remain hidden until you need them.这是 Wasp 设计中非常实用的一条。v0.12 文档中两处典型 hatch服务端project/server-config.mdserver.setupFn声明一个在服务启动时执行的函数可直接拿到 Express 的app实例挂自定义路由server.middlewareConfigFn用于定制中间件// src/myServerSetupCode.ts import { ServerSetupFn } from wasp/server import { Application } from express export const mySetupFunction: ServerSetupFn async ({ app }) { app.get(/customRoute, (_req, res) { res.send(I am a custom route) }) }客户端project/client-config.mdclient.setupFn提供等价的客户端启动钩子。这些字段不配置时完全不存在配置后又能直通底层框架——正是“平时隐藏、需要时打开”的 hatch 形态。当前仓库的 kitchen-sink 示例中server.setupFn/client.setupFn仍是同一机制说明这一设计从 v0.12 起是稳定的。3.4 Entity数据模型是一等公民Entity (data model) is a first-class citizen- defined via custom Wasp syntax and it integrates very closely with the rest of the features, serving as one of the central concepts around which everything is built.v0.12 中实体用自定义 Wasp 语法内嵌 PSL 代码块定义见>entity Task {psl id Int id default(autoincrement()) description String isDone Boolean psl}底层由 Prisma 承载psl即 Prisma Schema Language。各示例项目中的 schema.prisma 与 migrations 目录印证了这条链路Wasp 实体声明 → Prisma 数据模型 → SQL 迁移。3.5 开箱即用的 CRUD一条声明生成整套后端逻辑Out of the boxsupport for CRUD UI based on the Entities, to get you quickly going, but also customizable to some level.这条愿景在 v0.12 时代已经以Automatic CRUD功能落地data-model/crud.md一条crud声明就能让 Wasp 自动为实体生成创建、读取、更新、删除的服务端逻辑Queries 和 Actions并随实体定义的变化自动重新生成crud Tasks { entity: Task, operations: { getAll: { isPublic: true, // by default only logged in users can perform operations }, get: {}, create: { overrideFn: import { createTask } from src/tasks.js, }, update: {}, }, }其中getAll、get、update用默认实现create指定了自定义实现overrideFn正是 hatch 思想的体现默认能力开箱即用需要时逐操作覆盖且每个操作可独立控制公开/私有权限。3.6 “智能”操作Queries 与 Actions尽量消除客户端-服务端的心智负担Smart operations (queries and actions)that in most cases automatically figure out when to update, and if not it is easy to define custom logic to compensate for that. User worries about client-server gap as little as possible.v0.12 文档 contenteditable="false">【免费下载链接】waspThe batteries-included full-stack framework for the AI era. Develop JS/TS web apps (React, Node.js, and Prisma) using declarative code that abstracts away complex full-stack features like auth, background jobs, RPC, email sending, end-to-end type safety, single-command deployment, and more.项目地址: https://gitcode.com/GitHub_Trending/wa/wasp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考