In this PR, we introduce a new object called HttpServer and begin to deprecate HttpPlugin.

Main changes

1. Create HttpServer internal class. It accepts an IHttpServerAdapter which is the server implementation.
2. Pulled out the express implementation as an IHttpServerAdapter
3. Deprecated HttpPlugin, and made it use HttpServer + ExpressAdapter.
4. Changed BotBuilder/A2A/Mcp plugins to depend on HttpServer vs. HttpPlugin.
5. Added examples to show how powerful IHttpServerAdapter can be with different types of servers (hono, fastify).
6. Minor refactor of the jwt middleware such that we can reuse it in HttpServer and app.embed.

Why:

HTTP is a core part of our sdk. Our App object uses HTTP to set up a server, perform auth validations, and pipe the request to the handlers that are attached, and then return the response. Key part is that Http is a core part of App, not a plugin, since core functionality is dependent on it.
Even inside the App object, we were doing special casing for this Http"Plugin" whereas it should never have really been a plugin to begin with. By making it a plugin, we were exposing many non-plugin essential things to the plugin system in general.

So what should it have been? Well, HTTP Plugin had these responsibilities

1. Set up the express server
2. Perform validations if credentials were present
3. Pass the incoming request to App
4. Once App handlers have had a chance to process this incoming request, pass the response back to the server.

So, we introduce a new object called HttpServer whose responsibilities are essentially that ^. This object is not a plugin, but an object that's created by App itself.

Customization

Now this idealogical shift doesn't really warrant us doing this refactor, but we started seeing requests from folks who wanted to hook Teams functionality into existing servers, or replace the underlying server infra with a non-express server. Our recommendation was to rebuild a new HttpPlugin. But rebuilding this plugin is not simple (since we don't really document it anywhere, and didn't expect folks to build their own).
So HttpServer exposes an IHttpServerAdapter concept. To build the adapter, one simply needs to build out a handler for extracting request data, and a handler for responses. This means that you can build simple custom adapters for your own existing servers. (And if you don't pass one in, we'll build a default express one.) Examples of servers are in the http-adapters folder under examples/.

Adapter Interface

The IHttpServerAdapter interface adapters need to implement:

interface IHttpServerAdapter {
  registerRoute(method: HttpMethod, path: string, handler: HttpRouteHandler): void;
  serveStatic?(path: string, directory: string): void;
  start?(port: number): Promise<void>;
  stop?(): Promise<void>;
}

Handlers are pure functions — ({ body, headers }) → { status, body }. No framework-specific request/response objects leak through the abstraction.

Why registerRoute?

Some adapter patterns have the adapter own routing internally and just receive a single callback. But our SDK creates routes dynamically — app.function('myFunc') registers /api/functions/myFunc at runtime, in addition to the core /api/messages endpoint. The adapter needs a registerRoute method so that both HttpServer and app.function() can tell it what paths to listen on.

Optional methods

start/stop are optional — serverless adapters (Vercel, Lambda) don't need them. serveStatic is optional — only needed for tab hosting.

HttpMethod is currently just 'POST' (the only method the Teams protocol uses). It may expand to a union if needed.

Backward Compat

We've updated HttpPlugin to basically use HttpServer with an ExpressAdapter internally for backward compat. I don't think this should lead to any breaking changes (even if someone passes in their own HttpPlugin). (Tested BotBuilderPlugin, from examples, and it worked without any changes).
However, it should be noted that I marked HttpPlugin as deprecated in this PR, so it should be discouraged going forward, and after the next few versions, it'll be removed.

Testing

I tested by running the following examples:

1. Echo bot
2. Devtools
3. BotBuilder
4. HttpPlugin
5. Tabs
6. AI (streaming and regular completions)

skip-test-verification (added manifest for tabs)

PR Dependency Tree

• PR Simplify HTTP Plugin architecture #424
  • PR Introduce HttpServer (and begin deprecating HttpPlugin) #433 👈
    • PR Upgrade to express v5 #442

PR Dependency Tree

• PR Simplify HTTP Plugin architecture #424
  • PR Introduce HttpServer (and begin deprecating HttpPlugin) #433 👈

This tree was auto-generated by Charcoal