embr-multiservice-api

Backend API for the embr-multiservice-frontend sample. Two services. Two repos. Two embr quickstart deploys. One platform gap to flag.

What's it doing

• POST /api/summarize — calls Foundry's Responses API to summarize text.
• GET /api/stats — returns a request counter from Embr's embedded Valkey.
• Both endpoints require a shared X-Service-Token header, configured via SERVICE_TOKEN env var. The frontend service is configured with the same token.

Why this exists (the platform gap)

Embr's embr.yaml describes one app. There's no concept of:

• Multiple services in a single deployment unit
• Private/internal service-to-service URLs
• Service discovery within a project

So if you have a frontend that calls a backend, both have to live behind public ingress and the backend has to defend itself with its own auth. That's what SERVICE_TOKEN does here — a shared bearer token, ugly but it works.

What we'd want from Embr:

# Hypothetical multi-service embr.yaml
services:
  api:
    platform: python
    run: { port: 8000, startCommand: "..." }
    public: false             # not exposed on public ingress
  frontend:
    platform: node
    run: { port: 3000, startCommand: "..." }
    depends: [api]            # frontend gets API_URL injected, both share a network

…with an internal DNS name (http://api) that's only reachable from siblings in the same deployment, and an SPIFFE-style identity that auto-rotates instead of a long-lived shared secret.

Quick deploy

embr quickstart deploy embr-devs/embr-multiservice-api
embr variables set FOUNDRY_BASE_URL "<...>" -p $PROJ -e $ENV
embr variables set FOUNDRY_API_KEY  "<...>" -p $PROJ -e $ENV --secret
embr variables set FOUNDRY_MODEL_DEPLOYMENT "<deployment>" -p $PROJ -e $ENV
embr variables set SERVICE_TOKEN "$(openssl rand -hex 32)" -p $PROJ -e $ENV --secret
embr deployments trigger -c HEAD -p $PROJ -e $ENV

Save the API URL and the SERVICE_TOKEN — both go into the frontend's env vars next.