When you need it

Most apps are more than one process. A frontend calls an API, the API hands slow work to a background worker, and all three talk to Stripe, a database and a job queue. danwo can start the whole stack, put every process behind its proxy, and test it end to end.

When you need itCopy Anchor Link

Use the setup that matches what your app is:

You can mix them: a stack with an Inngest worker and a Postgres database is one config.

How it fits togetherCopy Anchor Link

1. danwo starts every app in the order you give, each with its own command and folder.
2. Each app is pointed at the proxy. Their calls to api.stripe.com or api.clerk.com reach emulators. Your code doesn't change.
3. Local services stay local. The apps reach each other, the Inngest dev server and your databases on this machine as usual.
4. Everything is recorded. Every app's calls, webhooks, sockets and log lines go into the test's flight record.

A small stackCopy Anchor Link

Here is a frontend that calls an API, with Stripe emulated and every other outside host blocked:

import { defineConfig, stackEnvironment, stripeService } from "@danwo/sdk"

export default defineConfig({
  testDir: "tests",
  readiness: { mode: "page+backend", settle: true },
  environment: () =>
    stackEnvironment({
      unmatched: "block",
      services: [stripeService()],
      apps: [
        {
          name: "web",
          command: "npm run dev",
          cwd: "apps/web",
          url: "http://localhost:3000",
          dependsOn: ["api"],
          env: ({ api }) => ({ VITE_API_URL: api ?? "" }),
        },
        {
          name: "api",
          command: "npm start",
          cwd: "apps/api",
          url: "http://localhost:4000",
          ready: { path: "/health" },
        },
      ],
    }),
})

danwo starts the API first and waits until /health answers. Then it starts the web app, with the API's address in VITE_API_URL. The browser opens the first app in the list, the web app.

NextCopy Anchor Link