后端微服务云原生【免费下载链接】midway A Node.js Serverless Framework for front-end/full-stack developers. Build the application for next decade. Works on AWS, Alibaba Cloud, Tencent Cloud and traditional VM/Container. Super easy integrate with React and Vue. 项目地址https://gitcode.com/gh_mirrors/mi/midway点击查看免费下载导读本文讲解 Midway Functional 一体化项目的构建与部署实践。核心思路是开发一体化部署分离化——开发阶段前端与后端 API 在同一工程、同一语言TypeScript内编写与调试构建阶段则拆分为独立的服务端产物与静态资源产物分别交给 Node 运行时与 Nginx/CDN 托管。读完本文你将掌握一体的构建脚本组织方式、dist/server与dist/web两类产物的边界以及面向 SSR/SSG 场景的basePath双运行时配置技巧。一、核心实践原则开发一体化部署分离化Functional 一体化项目的推荐实践是开发一体化服务端 API 与前端页面共享同一仓库、同一package.json、同一套 TypeScript 工具链通过vite等前端开发服务器提供热更新HMR接口与页面可以在本地一同联调部署分离化构建时不再耦合前端框架的打包流程而是把给 Node 运行的服务端与给静态服务器托管的静态资源分开产出各自独立部署、独立扩容。仓库中的 samples/react-functional-api/package.json 完整体现了这一分工——它是一个同时依赖midwayjs/bootstrap、midwayjs/koa、midwayjs/web-bridge与react、vite的一体化工程。二、推荐构建脚本与执行流程一体化工程的核心是把编译服务端与打包前端拆成两个独立命令再组合成一个总构建命令{ scripts: { dev: vite, build:server: tsc -p tsconfig.server.json, build:web: vite build, build: npm run build:server npm run build:web } }各命令的职责如下命令作用说明dev启动前端开发服务器基于vite开发期提供 HMR 热更新服务端 API 通常由本地 Node 进程承载可借助 mock 或独立启动build:server编译服务端使用tsc -p tsconfig.server.json按服务端专属 tsconfig 产出 Node 可执行产物build:web打包前端静态资源使用vite build产出浏览器可加载的静态文件build总构建先编译服务端、再打包前端保证两类产物一致性仓库中的 samples/react-functional-api/package.json 使用的正是这一脚本组织方式其build为pnpm run build:server pnpm run build:web并额外提供previewvite preview用于本地预览静态产物。服务端 tsconfig 的拆分要点build:server的关键是独立的tsconfig.server.json。samples/react-functional-api/tsconfig.server.json 展示了它的典型形态{ extends: ./tsconfig.json, compilerOptions: { module: ESNext, moduleResolution: Bundler, noEmit: false, allowImportingTsExtensions: false, rootDir: src/server, outDir: dist/server, sourceMap: true }, include: [src/server/**/*.ts] }要点分析extends公共配置复用根目录tsconfig.json中的target、strict、types等公共选项避免重复维护rootDir/outDir仅把src/server下的代码编译到dist/server从源头上隔离服务端与前端源码include限定范围只包含src/server/**/*.ts前端src/web的代码交给vite处理TypeScript 编译器不参与module: ESNextmoduleResolution: Bundler与现代前端构建工具链保持一致产物可直接被 Node ESM 加载。三、构建产物说明两类产物的边界构建完成后工程产出两类产物dist/server给 Node 运行的服务端代码包含bootstrap.js入口以及全部 API 实现、配置与依赖编译结果dist/web静态资源HTML、JS、CSS、图片等交给 Nginx/CDN 托管。这两类产物职责清晰产物运行方职责部署目标dist/serverNode.js 运行时承载 API 契约与业务逻辑监听 HTTP 端口云主机、容器Docker/K8s、Serverlessdist/web静态 Web 服务器提供前端页面与静态资源Nginx、CDN、对象存储静态托管仓库中的 samples/react-functional-api/tsconfig.server.json 将服务端输出到dist/server而前端vite build默认输出到dist/web可通过vite.config的build.outDir调整。两者互不干扰可独立发布、独立回滚。四、常见部署方式三步走1. 启动服务端编译完成后直接以 Node 运行服务端入口node dist/server/bootstrap.js仓库中 samples/functional-api-service/src/bootstrap.ts 展示了该入口的标准写法通过Bootstrap.configure({ baseDir: appDir }).run()启动 Midway 应用其中appDir取自import.meta.url所在目录确保产物移动后仍能正确定位应用根目录isDirectRun()判断脚本是否被直接执行从而兼容作为入口运行与作为模块被测试导入两种场景。该示例的start脚本即为node dist/bootstrap.js见 samples/functional-api-service/package.json。服务端监听端口与全局前缀在配置中声明例如 samples/functional-api-service/src/configuration.ts 中koa: { globalPrefix: /api, port: 7001, },即服务端默认监听7001端口所有 API 统一挂在/api前缀之下。2. 将dist/web托管到静态服务把dist/web目录整体上传至 Nginx 站点目录或 CDN 源站。若使用 Nginx核心配置示例如下示意具体路径按实际部署调整server { listen 80; server_name example.com; root /var/www/dist/web; # 静态资源产物目录 location / { try_files $uri $uri/ /index.html; # SPA 路由回退 } }对于纯 API 的后端工程则无需dist/web产物直接部署服务端即可参考 samples/functional-api-service 的 README构建后node dist/bootstrap.js随后用curl验证http://127.0.0.1:7001/api/health/ping。3. 前端请求通过同域或反向代理转到服务端 API浏览器侧请求走同域路径/api由 Nginx 反向代理到 Node 服务端location /api/ { proxy_pass http://127.0.0.1:7001; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }这样浏览器与 API 同源避免跨域问题服务端可通过全局前缀globalPrefix: /api与之精确对应见 samples/functional-api-service/src/configuration.ts 中的koa.globalPrefix配置。纯后端工程的简化部署如果你的项目不需要前端页面纯 API 服务构建脚本可以退化为单一tsc编译例如 samples/functional-api-service/package.json 中的build: tsc -p tsconfig.json、start: node dist/bootstrap.js。这种情况下不再有dist/web只有一份 Node 产物部署模型退化为传统后端服务。五、混合工程的部署注意点传统 Controller 与 Functional API 共存在从传统装饰器风格向 Functional 风格迁移的过渡期同一工程往往同时存在两类路由实现。仓库中的 samples/functional-api-hybrid 演示了这种混合形态src/api/functional.api.ts使用defineApi(/functional, ...)声明函数式路由src/controller/legacy.controller.ts使用Controller(/legacy)Get(/hello)声明传统装饰器路由。两者由同一个 configuration.ts 统一装配imports: [koa]并配置globalPrefix: /api、port: 7001构建与部署方式与纯 Functional 工程完全一致——这意味着迁移过程中无需改变部署架构两类路由在同一个 Node 进程内对外提供统一前缀的 API。六、SSR / SSG 场景分工与 basePath 配置在 SSR服务端渲染或 SSG静态站点生成场景下需要区分页面渲染与API 服务两个运行时沿用前端框架官方流程SSR/SSG 的构建、预渲染、水合hydration等工作交给前端框架如 Next.js 等服务端能力框架或 Vite 生态自身的官方流程处理不要与 Midway 的构建流程混为一谈Midway Functional 负责 API 契约和服务逻辑一体化工程中定义在src/server/api下的defineApi路由只负责输出类型安全、可校验的 API 契约与业务逻辑可参考 samples/react-functional-api/src/server/api/user.api.ts 的组织方式basePath建议区分浏览器和服务端运行时配置页面在浏览器中请求 API 时走相对路径/api同域、无需知道服务端内网地址而在服务端渲染阶段Node 进程请求 API 时需要显式指定服务端地址如内网http://127.0.0.1:7001/api避免依赖浏览器环境变量。原文档给出的核心配置basePath: { browser: /api, server: http://127.0.0.1:7001/api, }仓库中的 samples/react-functional-api/src/web/api/client.ts 是对这一配置的完整落地它通过midwayjs/web-bridge的createClient生成类型安全的 API 客户端并显式传入双运行时 basePathimport { createClient } from midwayjs/web-bridge; import { userApi } from ../../server/api/user.api.js; export const apiBridgeConfig { browserBasePath: /api, serverBasePath: http://127.0.0.1:7001/api, apiDir: src/server/api, } as const; export const api createClient( { user: userApi, }, { basePath: { browser: apiBridgeConfig.browserBasePath, server: apiBridgeConfig.serverBasePath, }, } );理解与使用要点browser 端值必须是与服务端globalPrefix如/api一致的相对路径浏览器在同域下直接命中由 Nginx 反向代理到 Node 的接口对应本文第四节第 3 步server 端值必须是服务端进程可达的完整地址协议 主机 端口 前缀因为在服务端渲染时不存在浏览器同源约定必须显式给出目标地址apiDir声明服务端 API 源码目录配合工具链实现前端引用服务端路由类型的跨运行时类型共享这正是开发一体化的类型基础环境差异server端地址在实际生产环境应替换为服务端真实可达地址如容器网络内地址或负载均衡地址示例中的127.0.0.1:7001仅适用于本地开发。七、开发期与部署期的衔接建议开发期vite提供前端 HMR服务端可借助midwayjs/mock或独立启动node dist/server/bootstrap.js提供真实 API实现页面 接口同窗联调验证产物部署前在本机执行npm run build随后分别验证node dist/server/bootstrap.js可启动、dist/web可用vite preview或任意静态服务器预览确认两类产物各自可用后再发布关注端口与前缀一致性port、globalPrefix见各 sample 的 configuration.ts与 Nginxproxy_pass、basePath.browser三者必须对齐否则会出现页面可达但 API 404 的部署事故。结语Midway Functional 一体化项目的部署模型可以概括为一句原则开发一体化部署分离化。前端框架只负责页面Midway Functional 只负责 API 契约与服务逻辑构建期以tscvite各自产出dist/server与dist/web部署期由 Node、Nginx/CDN 分别承载并通过同域反代连通。SSR/SSG 场景下再用双运行时basePath打通浏览器直连 / 服务端内网调用两条通路。这套实践在仓库的 samples/react-functional-api、samples/functional-api-hybrid 与 samples/functional-api-service 三个示例中均有可直接运行的完整实现可作为新项目脚手架或迁移参考。赞分享后端微服务云原生【免费下载链接】midway A Node.js Serverless Framework for front-end/full-stack developers. Build the application for next decade. Works on AWS, Alibaba Cloud, Tencent Cloud and traditional VM/Container. Super easy integrate with React and Vue. 项目地址https://gitcode.com/gh_mirrors/mi/midway点击查看免费下载相关推荐深度解析DS4Windows架构跨平台手柄兼容性解决方案的技术实现深度解析DS4Windows架构跨平台手柄兼容性解决方案的技术实现 DS4Windows是一款基于ViGEm虚拟游戏设备框架的跨平台手柄兼容性解决方案通过创后端微服务云原生Darklang CLI工具链开发调试部署一体化Darklang CLI工具链开发调试部署一体化 概述 Darklang CLI工具链是Darklang语言生态系统的核心组件为开发者提供从代码编写到部署运jcv_voronoi实战案例从简单点集到复杂Voronoi图的完整实现jcv_voronoi实战案例从简单点集到复杂Voronoi图的完整实现 jcv_voronoi是一个高效的C语言实现库用于创建2D Voronoi图和De上一篇Sonner的版本发布检查清单确保质量的最后一步下一篇Maestro引擎核心组件揭秘StepRuntime与WorkflowRunner协作机制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考