后端数据库GraphQL【免费下载链接】prisma1 Database Tools incl. ORM, Migrations and Admin UI (Postgres, MySQL MongoDB) [deprecated]项目地址https://gitcode.com/gh_mirrors/pr/prisma1点击查看免费下载本指南基于 Prisma 1.x 开源仓库的官方 FAQ 文档docs/1.13/05-FAQ/03-Prisma-Cloud.md系统讲解 Prisma Cloud 中 Workspace、Prisma Server、Service 三者的组织关系覆盖三种服务器类型本地自托管 / Demo / 私有、团队权限、多环境部署、免费额度、数据库连接与备份策略等核心问题。读完本文你将理解prisma deploy背后选服务器 → 选工作区 → 写 endpoint的完整机制并能依据仓库源码判断每个配置项的真实行为与适用前提。Workspace 是什么Prisma Cloud 的组织单元原 FAQ 用一个很形象的类比解释了 Workspace 的概念可以把 Workspace 粗略理解为类似 GitHub Organization 的组织容器它是个人账号、Prisma Server 与服务Service的集合。官方文档给出的三条关联规则如下一个 Workspace 可以关联多个个人账号一个个人账号也可以加入多个 Workspace多对多关系。一个 Workspace 可以关联多个 Prisma Server但一个 Prisma Server 永远只属于恰好一个 Workspace一对多关系。由于一个 Prisma Server 可以承载多个 Service因此一个 Workspace 可以间接关联多个 Service。注意FAQ 中提到的Prisma Server均特指在 Prisma Cloud 中创建的私有 Prisma Server对于自托管self-hosted服务器和 Demo 服务器上述部分规则并不成立——例如自托管服务器并不隶属于任何 Workspace。Workspace 的存在直接体现在服务的 endpoint 结构中。从源码看CLI 会在校验配置时强制要求共享集群shared cluster携带 workspace slug在 cli/packages/prisma-yml/src/PrismaDefinition.ts 的validate()方法中若cluster属性缺少 workspace slug 会直接报错并提示合法的 Demo endpoint 格式为https://eu1.prisma.sh/myworkspace/service-name/stage-name也就是说endpoint 中的myworkspace段正是 workspace 的唯一标识。在 cli/packages/prisma-yml/src/Cluster.ts 的getApiEndpoint()中可以看到 workspace slug 如何拼入最终 API 地址${baseUrl}/${workspaceSlug}/${service}/${stage}从源码结构看Workspace 是一个逻辑命名空间它把用户、服务器和服务归并到同一隔离域下从而保证不同 Workspace 之间的服务即使同名也不会冲突。团队成员的权限管理现状关于权限FAQ 的回答非常直白目前该文档编写时所有被邀请加入 Prisma Cloud 项目的团队成员都拥有完整访问权限更细粒度的访问与权限管理功能当时仍在规划中coming soon。这一点对团队协作的实操含义是如果你邀请同事加入同一个 Workspace他默认就能访问该 Workspace 下所有私有服务器上的全部服务因此在生产环境共享 Workspace 时应当谨慎。细粒度的角色划分只读 / 只写 / 按服务授权等在当时的版本中并不存在需要依赖其他手段例如为服务配置secret来保护管理 API或使用PRISMA_MANAGEMENT_API_SECRET环境变量做服务端鉴权来补充安全边界。Prisma Server 与 Prisma Service运行时与部署单元两者关系Prisma Server 是零个或多个 Prisma Service 的运行时环境runtime environment。要部署一个 Prisma Service执行prisma deploy命令前提是有一个可用的 Prisma Server。这在部署命令源码中可以得到印证cli/packages/prisma-cli-core/src/commands/deploy/deploy.ts 的run()流程为——读取prisma.yml→ 解析 service 与 stage → 通过EndpointDialog选择集群 →initClusterClient→ 检查项目是否已存在 →addProject→ 真正执行deploy迁移。三种 Prisma Server 类型FAQ 把 Prisma Server 分为三类这是理解整个部署模型的关键类型说明典型用途本地 / 自托管Local / self-hosted通过 Docker 在本地或任意云厂商主机上自行搭建完全自主可控生产环境、离线开发DemoPrisma Cloud 提供Prisma Cloud 提供的免费托管环境有速率限制与存储上限免费但仅适合学习、原型与开发学习、原型验证、开发私有PrivatePrisma Cloud 提供在创建服务器时连接你自己的数据库由 Prisma Cloud 托管生产、预发布等正式环境Demo 服务器与私有服务器在仓库源码中被建模为 Cluster 对象的不同属性。在 cli/packages/prisma-yml/src/Cluster.ts 中Cluster类拥有local、shared、isPrivate、workspaceSlug等布尔/字符串属性分别标记本地的 / 共享的Demo/ 私有的 / 所属工作区。两个 Demo 集群prisma-eu1、prisma-us1的固定端点定义在 cli/packages/prisma-yml/src/constants.tsexport const clusterEndpointMap: { [key: string]: string } { prisma-eu1: https://eu1.prisma.sh, prisma-us1: https://us1.prisma.sh, }而 cli/packages/prisma-yml/src/Environment.ts 则用sharedClusters: string[] [prisma-eu1, prisma-us1]将其标记为共享集群并在登录后通过 Cloud API 的prismaCliGetClusters查询见 Environment.ts拉取当前 Workspace 下的全部集群列表含私有集群及其 endpoint。从命令行视角理解三种服务器在交互式部署时CLI 会引导用户做出选择。相关逻辑集中在 cli/packages/prisma-cli-core/src/utils/EndpointDialog.ts 的getClusterQuestion()它会提供Use existing database / Create new database走本地 Docker 路线对应自托管Demo server MySQL database免费 Demo 环境未登录时会先要求登录见getDemoCluster()对应源码 EndpointDialog.tsUse other server手动输入任意运行中 Prisma Server 的 endpoint对应自托管/自定义服务器。选择 Demo 服务器后CLI 会先 ping 两个区域并展示实测延迟EU_WEST_1对应demo-eu1US_WEST_2对应demo-us1见 EndpointDialog.ts方便你按地理位置选择延迟更低的区域。这与教程 docs/1.13/03-Tutorials2/01-Setup-Prisma/01-Demo-Server.md 中选择demo-eu1或demo-us1的指引一致。多阶段Multi-staging开发工作流多环境dev/staging/prod是团队开发的标准诉求。FAQ 给出的核心结论是多个阶段可以共用同一个 Prisma Server因为一个 Server 能承载多个 Service你可以把代表不同阶段/环境的 Service如dev、staging、prod部署到同一台服务器上并非必须为每个阶段单独开一台服务器。生产环境强烈建议独占服务器为了确保dev或staging上的任何操作都不会对prod产生负面影响推荐把生产环境部署到独立的 Prisma Server上。理想情况下其他阶段/环境也各自独占一台以最小化相互影响的风险。开发环境可灵活选择本地 Prisma Server 或 Prisma Cloud 的 Demo 服务器都可以按需充当开发环境。从源码看一个 Server 承载多阶段服务是天然支持的服务名service 阶段名stage共同决定唯一 endpointgetApiEndpoint()中${baseUrl}/${workspace}/${service}/${stage}的拼接逻辑见 Cluster.ts 对应的 Cluster.ts因此在同一服务器上部署myservice/dev、myservice/staging、myservice/prod互不干扰。部署时的具体行为还受 deploy 命令参数影响。在 cli/packages/prisma-cli-core/src/commands/deploy/deploy.ts 中可以看到常用的阶段运维参数参数说明--force/-f接受 schema 变更可能带来的数据丢失--new/-n强制进入交互模式重新选择集群--dry-run/-d只做部署预演不真正应用变更--no-migrate禁用迁移需 Prisma 1.26--no-generate禁用隐式客户端生成--no-seed首次部署时不执行 seed--env-file/-e指定注入环境变量的.env文件路径免费版本Demo 服务器的限制与适用边界FAQ 明确回答了Prisma Cloud 是否有免费版本部署到 Demo 服务器是免费的但必须清楚它的两个硬性限制速率限制rate limit约 10 次请求 / 10 秒存储上限storage bound约 100 MB。因此 Demo 服务器只适合学习、原型验证与开发用途。任何生产使用场景都应该使用自托管服务器或私有 Prisma Server。注意要使用 Demo 服务器前提是拥有 Prisma Cloud 账号FAQ 原话you need a Prisma Cloud account to deploy to a Demo server。这一点在源码中有直接呼应未登录时getDemoCluster()会先调用this.client.login()完成登录再继续EndpointDialog.ts而在部署到非公开集群即私有集群时deploy 命令会校验登录态或PRISMA_MANAGEMENT_API_SECRET否则触发登录流程deploy.ts。会话凭据cloudSessionKey会持久化到用户主目录的~/.prisma/config.yml见 Environment.ts 的saveGlobalRC()。如何连接数据库FAQ 的关键结论是每个 Prisma Server 只被一个数据库支撑未来才支持同一 Server 连接多个数据库且数据库是在 Server 初次创建时绑定的之后不能随意更换。也就是说连接数据库这个动作发生在创建私有 Prisma Server 的那一步而不是部署服务时。创建时你需要提供数据库连接信息。在 CLI 的交互流程中DatabaseCredentials接口见 EndpointDialog.ts定义了收集的凭据字段export interface DatabaseCredentials { type: DatabaseType // mysql | postgres | mongo | sqlite host?: string port?: number user?: string password?: string database?: string schema?: string ssl?: boolean uri?: string // Mongo 使用连接串 }各数据库类型的默认端口在 EndpointDialog.ts 中有定义PostgreSQL 5432、MySQL 3306、MongoDB 27017。选择Create new database时CLI 还会自动生成对应的docker-compose.yml数据库服务定义Postgres / MySQL 5.7 / MongoDB 3.6 的镜像与prisma/prisma默认凭据见 EndpointDialog.ts选择Use existing database时则会先通过connector.listSchemas()验证连接、再决定走 introspection已有数据还是使用默认 datamodel空库相关流程见 EndpointDialog.ts。自动备份Prisma 只做数据库之上的那一层FAQ 对备份问题的回答体现了 Prisma 的架构定位Prisma 只是运行在你数据库之上的一个层a layer on top of your database数据库本身始终由你完全掌控。因此你拥有备份策略的全部主动权与灵活性——备份/恢复仍然走你熟悉的数据库原生能力如 MySQL 的 mysqldump、PostgreSQL 的 pg_dump、云厂商快照等无论使用自托管、Demo 还是私有服务器Prisma 本身并不替你管理数据库快照FAQ 提到未来 Prisma Cloud 计划简化备份工作流例如支持自动的时间点恢复point-in-time restores但这在当时属于规划中的能力不能视为现有功能。这一薄层定位同样体现在架构上服务端各数据库连接器独立实现仓库中server/connectors目录下分别有 api-connector-jdbc、api-connector-mongo、api-connector-mysql、api-connector-postgres、api-connector-sqlite 等连接器模块Prisma 负责把 GraphQL API、数据模型与具体数据库对接而底层数据的持久化、备份与恢复仍属于数据库本身的管理职责。快速实操从零把服务部署到 Prisma Cloud结合上面的概念这里给出一个端到端的最小实操路径依据教程 docs/1.13/03-Tutorials2/01-Setup-Prisma/01-Demo-Server.md 与 CLI 源码整理第 1 步安装 CLInpm install -g prisma # 或 # yarn global add prisma第 2 步初始化服务prisma init hello-worldCLI 会询问使用现有 Prisma Server 还是新建一个。选择Demo server后若未注册 Prisma Cloud浏览器会打开注册页登录后选择区域demo-eu1或demo-us1CLI 会显示实测延迟再连续按两次 Enter 确认服务名与 stage 的默认值。第 3 步查看生成的配置目录下会生成prisma.yml与datamodel.graphql典型的prisma.yml内容为endpoint: https://eu1.prisma.sh/alice-doe-fd2dcf/hello-world/dev datamodel: datamodel.graphql其中alice-doe-fd2dcf是你 Prisma Cloud Workspace 的 ID每人不同hello-world是服务名dev是 stage——三者共同构成最终 API endpoint。第 4 步部署与更新prisma deploy # 部署首次部署会自动建库建表 prisma deploy --force # 接受 schema 变更可能造成的数据丢失 prisma deploy --dry-run # 预演不真正应用部署成功后服务即运行在所选 Server 上Demo 服务器免费但有速率与存储上限私有服务器则连接你自己提供的数据库。小结Prisma Cloud 的体系可以一句话概括Workspace 是组织边界Prisma Server 是运行单元Service 是部署单元数据库在创建 Server 时绑定。FAQ 文档明确了多阶段部署可共享服务器、生产建议独占、Demo 免费但有 10 次/10 秒与 100 MB 限制、备份完全交由数据库原生策略等关键结论。在仓库源码层面这些规则分别落实在 Cluster.ts、Environment.ts、constants.ts、PrismaDefinition.ts 以及 EndpointDialog.ts 与 deploy.ts 中理解这些实现细节有助于你在真实项目中准确判断部署行为与配置边界。赞分享后端数据库GraphQL【免费下载链接】prisma1 Database Tools incl. ORM, Migrations and Admin UI (Postgres, MySQL MongoDB) [deprecated]项目地址https://gitcode.com/gh_mirrors/pr/prisma1点击查看免费下载相关推荐Prisma Cloud 实战指南Workspace、Prisma Server 类型与多环境部署工作流解析Prisma Cloud 实战指南Workspace、Prisma Server 类型与多环境部署工作流解析 Prisma Cloud 是 Prisma 官方后端数据库GraphQLPrisma Cloud 完全指南Workspace、Prisma 服务器类型与多阶段部署实战Prisma Cloud 完全指南Workspace、Prisma 服务器类型与多阶段部署实战 Prisma Cloud 是 Prisma 官方提供的一套托管后端数据库GraphQLPrisma Cloud 服务器与多阶段部署实战Workspace、Demo/Private/本地服务器与数据库备份完全指南Prisma Cloud 服务器与多阶段部署实战Workspace、Demo/Private/本地服务器与数据库备份完全指南 本指南以 Prisma 1.x后端数据库GraphQL创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
