[APPS] Add vite dev server middleware for backend functions

[sdkennedy2]

Motivation

Developers building high code apps with backend functions need a way to test those functions locally during vite dev without deploying. This PR adds a Vite dev server middleware that bundles and executes backend functions on-the-fly, using the same vite.build() approach established in #292.

Changes

Added a Vite dev server middleware that registers via configureServer and intercepts two endpoints:

• POST /__dd/debugBundle — returns the bundled script for inspection
• POST /__dd/executeAction — bundles the function, sends it to Datadog's query preview-async API, polls for the result, and returns it

Why vite.build() instead of the dev server's transform pipeline?

Vite's dev server (transformRequest, ssrLoadModule) is designed for serving individual modules on-demand — it doesn't produce bundled output. But Datadog's execution API needs a complete, self-contained script with all dependencies resolved and inlined into one file. vite.build({ write: false }) runs a mini Rollup build in memory, producing exactly that.

Why the hacky import('vite')?

The dev server middleware needs to call vite.build(), but we can't add vite as a dependency of the apps plugin. The apps plugin is bundler-agnostic — it's compiled into @datadog/webpack-plugin, @datadog/esbuild-plugin, etc. Adding vite as a dependency would force every bundler's published package to pull in vite.

Instead, we use a variable indirection to make the import opaque to Rollup's static analysis:

const viteModule = 'vite';
const { build: viteBuild } = await import(/* @vite-ignore */ viteModule);

This is safe because: the code only runs inside configureServer, which is a Vite-only hook — vite is guaranteed to be installed.

Key implementation details:

• configFile: false prevents recursion (user's vite.config.ts includes the Datadog plugin)
• treeshake: false + inlineDynamicImports: true keeps action-catalog bridges and argument passing fully intact
• generateDevVirtualEntryContent() inlines args as JSON (vs the production template expression ${backendFunctionArgs})
• Long-polling with up to 10 retries (~30s server-side timeout each) for execution results

New files:

• backend/vite/dev-server.ts — middleware, Vite-based bundling, Datadog API integration
• backend/vite/dev-server.test.ts — unit tests

Modified files:

• backend/virtual-entry.ts — added generateDevVirtualEntryContent() for dev mode
• backend/vite/index.ts — registers middleware via configureServer hook
• backend/index.ts — added auth to BackendPluginContext
• src/index.ts — passes auth credentials to the backend plugin

QA Instructions

1. Scaffold or use an existing high code app with a backend/ directory containing a function
2. Link the local build-plugins vite plugin
3. Run yarn dev in build-plugins, then start the app: NODE_TLS_REJECT_UNAUTHORIZED=0 dd-auth --domain="dd.datad0g.com" --actions-api -- npx vite
4. Test debug bundle: curl -X POST http://localhost:5173/__dd/debugBundle -H "Content-Type: application/json" -d '{"functionName": "yourFunction", "args": []}'
5. Test execution: curl -X POST http://localhost:5173/__dd/executeAction -H "Content-Type: application/json" -d '{"functionName": "yourFunction", "args": ["test"]}'

Blast Radius

• Only affects the vite dev server when apps.backendDir is configured and backend functions are discovered
• No impact on production builds or non-vite bundlers
• The middleware only activates when auth credentials are available

Documentation

• How to reliably make frontend production changes
• PR Description Guidelines
• Deploy steps

[sdkennedy2]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• [APPS] Add vite dev server middleware for backend functions #291 👈 (View in Graphite)
• [APPS] Use separate vite.build() for backend functions, drop Rollup backend support #292
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[sarenji]

Some initial thoughts on this

[sarenji]

Could we do dependency injection somehow, by passing a vite build function to this middleware, avoiding the hassle of importing Vite within createDevServerMiddleware?

We could also externalize vite if necessary.

[sarenji]

Consider using exponential backoff, plus a jitter, for cases where the API has gone down and is trying to get back up

I also see async-retry usage here, and maybe doRequest in general is a method we can reuse.

[sarenji]

This seems like a potential source of flakiness and test slowdown. Can we be more exact on what we are waiting for?

[sarenji]

Fundamentally I do not understand this because Connect middleware is not async so it's confusing to me how this is working.