This PR upgrades our systems from express v4 to express v5.
The changes applicable to us are fairly minimal



#### PR Dependency Tree


* **PR #424**
  * **PR #433**
    * **PR #442** 👈

This tree was auto-generated by
[Charcoal](https://github.com/danerwilliams/charcoal)

This PR upgrades our systems from express v4 to express v5.
The changes applicable to us are fairly minimal



#### PR Dependency Tree


* **PR #424**
  * **PR #433**
    * **PR #442** 👈

This tree was auto-generated by
[Charcoal](https://github.com/danerwilliams/charcoal)

This PR upgrades our systems from express v4 to express v5.
The changes applicable to us are fairly minimal



#### PR Dependency Tree


* **PR #424**
  * **PR #433**
    * **PR #442** 👈

This tree was auto-generated by
[Charcoal](https://github.com/danerwilliams/charcoal)

This PR upgrades our systems from express v4 to express v5.
The changes applicable to us are fairly minimal



#### PR Dependency Tree


* **PR #424**
  * **PR #433**
    * **PR #442** 👈

This tree was auto-generated by
[Charcoal](https://github.com/danerwilliams/charcoal)

This PR upgrades our systems from express v4 to express v5.
The changes applicable to us are fairly minimal



#### PR Dependency Tree


* **PR #424**
  * **PR #433**
    * **PR #442** 👈

This tree was auto-generated by
[Charcoal](https://github.com/danerwilliams/charcoal)

This is a python adaptation of
microsoft/teams.ts#424.

Separate activity sending from HTTP transport layer

The previous architecture tightly coupled HTTP transport concerns with
activity sending logic:

**Previous Architecture:**
```
HttpPlugin (transport) → implements ISender (sending)
                      → has send() method (creates new Client per call)
                      → has createStream() method
                      → knows about Activity protocol details

ActivityContext → depends on ISender plugin
               → cannot work without transport plugin
               → conflates transport and sending concerns
```

There are a few issues with this:
- HttpPlugin created NEW Client instances on every send() call. So
there's really no benefit of this logic being in the "httpclient"
plugin.
- Transport plugins (HttpPlugin) were forced to implement
send/createStream. This makes it more cumbersome to build your own
HttpPlugin with your own servier.
- Users couldn't "bring their own server" without implementing ISender
- ActivityContext was tightly coupled to plugin architecture. ("Sender"
was coupled with an activity, without any necessary benefits.)

## New Architecture

```
HttpPlugin (transport) → only handles HTTP server/routing/auth
                      → emits CoreActivity (minimal protocol knowledge)
                      → just passes body payload to app

ActivitySender (NEW)  → dedicated class for sending activities
                     → receives injected, reusable Client
                     → handles all send/stream logic
                     → private to App class

ActivityContext       → uses ActivitySender now, which is not a plugin
```

In this PR, I am mainly decoupling responsibilities of HttpPlugin from
being BOTH a listener AND a sender, to being just a listener. The sender
bit is now separated to a different `ActivitySender` class. Other than
better code organization, the main thing this lets us do is **not
require the app to run to be able to send proactive messages**. This is
a huge plus point because now the App can be used in scenarios where it
doesn't necessarily need to _listen_ to incoming messages (like agentic
notifications!)

---------

Co-authored-by: Claude Opus 4.6 <[email protected]>

This PR upgrades our systems from express v4 to express v5.
The changes applicable to us are fairly minimal



#### PR Dependency Tree


* **PR #424**
  * **PR #433**
    * **PR #442** 👈

This tree was auto-generated by
[Charcoal](https://github.com/danerwilliams/charcoal)

This PR upgrades our systems from express v4 to express v5.
The changes applicable to us are fairly minimal



#### PR Dependency Tree


* **PR #424**
  * **PR #433**
    * **PR #442** 👈

This tree was auto-generated by
[Charcoal](https://github.com/danerwilliams/charcoal)

This PR upgrades our systems from express v4 to express v5.
The changes applicable to us are fairly minimal



#### PR Dependency Tree


* **PR #424**
  * **PR #433**
    * **PR #442** 👈

This tree was auto-generated by
[Charcoal](https://github.com/danerwilliams/charcoal)

This PR upgrades our systems from express v4 to express v5.
The changes applicable to us are fairly minimal

* **PR #424**
  * **PR #433**
    * **PR #442** 👈

This tree was auto-generated by
[Charcoal](https://github.com/danerwilliams/charcoal)

This PR upgrades our systems from express v4 to express v5.
The changes applicable to us are fairly minimal

* **PR #424**
  * **PR #433**
    * **PR #442** 👈

This tree was auto-generated by
[Charcoal](https://github.com/danerwilliams/charcoal)

This PR upgrades our systems from express v4 to express v5.
The changes applicable to us are fairly minimal

* **PR #424**
  * **PR #433**
    * **PR #442** 👈

This tree was auto-generated by
[Charcoal](https://github.com/danerwilliams/charcoal)

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:

```typescript
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 #424**
  * **PR #433** 👈
    * **PR #442**


#### PR Dependency Tree


* **PR #424**
  * **PR #433** 👈

This tree was auto-generated by
[Charcoal](https://github.com/danerwilliams/charcoal)

---------

Co-authored-by: Claude Opus 4.6 <[email protected]>