Apps with a server

When an app needs to keep an API key secret, store files or call another service, it needs server code. On Inhaus that is a module with a fetch handler:

import { getUser } from '@inhaus/sdk';

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const user = getUser(request);
    const url = new URL(request.url);

    if (url.pathname === '/api/hello') {
      return Response.json({ hello: user?.name });
    }
    return new Response('Not found', { status: 404 });
  },
};

Where Inhaus looks for the server

The entry you pass to deploy_app, or the first of these that exists:

_worker.js
worker.ts       worker.js       worker.mjs
server.ts       server.js
src/worker.ts   src/worker.js
src/server.ts   src/server.js
api/index.ts    api/index.js

Static files and a server together

If the app also has an index.html (see Static sites), static files are served first and every other request goes to your fetch handler. A common layout:

my-app/
├── public/
│   ├── index.html
│   └── app.js          fetch('/api/leads')
├── worker.ts           handles /api/*
├── migrations/
│   └── 0001_init.sql
└── package.json

The runtime

Server code runs on a fast, lightweight JavaScript runtime that starts in milliseconds and scales to zero when nobody uses the app. It supports the standard web APIs (fetch, Request, Response, URL, crypto, streams). It does not include Node.js built-ins like fs, child_process or net. Packages that need them will fail to build. For example, the pg PostgreSQL driver fails with Could not resolve "events".

What is in env

Calling outside services

Call other websites with fetch, and keep their keys in secrets. The security scan checks every website the code calls against your workspace's allowed domains. A domain that is not on the list is a blocking issue until an admin allows it or the call is removed.