Build a Praxa backend with Nuxt

​

Prerequisites

• a trusted server runtime and application authentication boundary;
• a disposable personal workspace Praxa key with only the tutorial’s required scopes;
• synthetic input plus a persisted application request ID for replay tests;
• a fake upstream for unit tests and a non-production environment for canaries;
• an acceptance assertion that proves the Nitro route owns private runtime config and admits one replay-safe task.

​

1. Add private runtime config

export default defineNuxtConfig({
  runtimeConfig: {
    praxaApiKey: "",
    public: {
      apiBase: "/api",
    },
  },
});

​

2. Add the Nitro route

import { createHash } from "node:crypto";

export default defineEventHandler(async (event) => {
  const user = await requireApplicationUser(event);
  const body = await readBody<{ task?: unknown; requestId?: unknown }>(event);

  if (
    typeof body.task !== "string" ||
    body.task.length < 1 ||
    body.task.length > 16_000 ||
    typeof body.requestId !== "string" ||
    body.requestId.length < 16 ||
    body.requestId.length > 128
  ) {
    throw createError({ statusCode: 400, statusMessage: "Invalid request" });
  }

  const config = useRuntimeConfig(event);
  if (!config.praxaApiKey) {
    throw createError({ statusCode: 503, statusMessage: "Praxa unavailable" });
  }

  const idempotencyKey =
    "nuxt:" +
    createHash("sha256")
      .update(`${user.id}\0${body.requestId}`)
      .digest("hex");

  const response = await $fetch.raw("https://api.praxa.io/v1/execute", {
    method: "POST",
    headers: {
      authorization: `Bearer ${config.praxaApiKey}`,
      "idempotency-key": idempotencyKey,
    },
    body: {
      apiVersion: "v1",
      requestId: idempotencyKey,
      mode: "task",
      task: { input: body.task },
      idempotencyKey,
    },
    ignoreResponseError: true,
  });

  setResponseHeader(event, "cache-control", "no-store");
  setResponseStatus(event, response.status);
  return response._data;
});

​

3. Call the route from Vue

<script setup lang="ts">
const task = ref("");
const pending = ref(false);
const result = ref<unknown>();

async function submit() {
  pending.value = true;
  try {
    result.value = await $fetch("/api/tasks", {
      method: "POST",
      body: { task: task.value, requestId: crypto.randomUUID() },
    });
  } finally {
    pending.value = false;
  }
}
</script>

<template>
  <form @submit.prevent="submit">
    <textarea v-model="task" maxlength="16000" required />
    <button :disabled="pending">Submit task</button>
  </form>
</template>

​

4. Test the boundary

1. No application session returns 401 before $fetch is called.
2. Invalid input returns 400 before $fetch is called.
3. Missing private runtime config returns a safe 503.
4. A valid request uses the private key and ignores caller ownership fields.
5. Same user and request ID produce the same idempotency key.
6. Different users produce different keys.
7. The response is no-store and contains no authorization value.

​

Troubleshooting

​

Best practices

• Pass event to useRuntimeConfig in server routes.
• Authenticate before reading or forwarding work.
• Bound request bodies and rate-limit per principal.
• Do not forward browser headers wholesale to Praxa.
• Reconcile admitted runs through a server-side read route.
• Scan the generated client bundle for credential-shaped values.

​

Optimize for production

• Reuse one configured HTTP or SDK client per process and bound concurrent upstream work.
• Prefer durable admission plus asynchronous readback over holding application requests open.
• Cache only non-sensitive, tenant-scoped reads within their documented freshness window.
• Measure p50/p95 latency, admission-to-terminal time, retries, conflicts, and connection reuse before tuning.

​

Cleanup and next steps

1. Revoke the disposable Praxa key and require a later request to fail.
2. Remove synthetic application records and any temporary environment files.
3. Cancel or archive unresolved test runs according to the application policy.
4. Retain only redacted request, run, and verification identifiers needed for the test record.

​

Frequently asked questions

​

What proves this tutorial works?

​

Can a browser, mobile app, or model prompt hold the credential?

​

How should an ambiguous mutation be retried?

​

What should we monitor after release?