Apollo Server 4部署方式对比：standalone与expressMiddleware

核心差异 #

这两种方式本质是GraphQL服务与HTTP层的绑定关系不同：

• startStandaloneServer：Apollo官方封装的独立HTTP服务器，完全不依赖Express，把GraphQL服务所需的基础HTTP能力（请求解析、CORS、Sandbox）都内置了
• expressMiddleware：将Apollo Server作为Express的一个中间件，依托Express的HTTP框架运行，和你之前写MERN API的模式完全一致

优缺点对比 #

startStandaloneServer #

优点

• 零成本启动：不用写Express的基础配置（比如app.listen、CORS设置），几行代码就能跑起GraphQL服务，适合快速搭原型或纯GraphQL项目
• 内置最佳实践：默认开启GraphQL Sandbox、处理CORS、请求体解析，不用自己折腾这些基础配置
• 轻量无冗余：少了Express及其依赖，项目体积更小，部署时更少依赖项

缺点

• 扩展性受限：如果要集成Express生态的中间件（比如自定义日志、REST接口、第三方认证中间件），需要额外做适配，不如直接用Express方便
• HTTP层定制弱：没法像Express那样灵活控制路由规则、请求拦截逻辑，比如想给GraphQL接口加特殊的限流规则，操作起来更麻烦

expressMiddleware #

优点

• 无缝复用现有经验：对你这种有MERN开发背景的人来说，直接把GraphQL塞进已有的Express项目里，之前写的mongoose连接、JWT验证中间件都能直接用
• 高度定制化：完全掌控HTTP层，既能跑GraphQL，又能保留原有的REST接口，还能随意加Express生态的中间件（比如helmet安全防护、compression压缩）
• 生态成熟：Express社区的工具、中间件都能直接用，遇到问题更容易找到解决方案

缺点

• 配置繁琐：得手动搭Express的基础架子，处理CORS、错误捕获、静态文件这些基础工作，比startStandaloneServer多写不少代码
• 依赖冗余：引入Express及相关依赖，增加了项目的复杂度和打包体积

关键注意事项 #

JWT授权 #

• startStandaloneServer：在创建服务器时通过context配置项直接解析请求头的JWT，示例：

  const server = new ApolloServer({ typeDefs, resolvers });
  const { url } = await startStandaloneServer(server, {
    context: async ({ req }) => {
      const token = req.headers.authorization?.split(' ')[1];
      const user = await verifyToken(token);
      return { user };
    },
  });
  

• expressMiddleware：复用你之前的Express JWT中间件，先在Express层验证token，再把用户信息传到GraphQL的context里，示例：

  // 先在Express层加JWT中间件
  app.use('/graphql', jwtMiddleware, expressMiddleware(server, {
    context: async ({ req }) => ({ user: req.user }),
  }));
  

复杂查询与变更 #

两种方式对GraphQL的核心功能（查询、变更、订阅）支持完全一致，业务逻辑的写法没有任何区别，差异只在HTTP层的处理逻辑，不用纠结核心功能的兼容性。

订阅功能 #

• startStandaloneServer默认支持WebSocket订阅，不用额外配置
• expressMiddleware需要手动集成WebSocket服务（比如用ws库），配置相对繁琐一些

部署 #

• startStandaloneServer：部署简单，直接启动即可，适合容器化部署（Docker）
• expressMiddleware：和传统Express项目部署流程一致，适合已有Express运维体系的场景

内容的提问来源于stack exchange，提问作者Rher