Skip to main content
Version: Next

Server config

You can configure the behavior of the server via the server field of app spec:

main.wasp.ts
import { app } from "@wasp/spec"
import { myMiddlewareConfigFn, mySetupFunction } from "./src/myServerSetupCode" with { type: "ref" }

export default app({
name: "MyApp",
server: {
setupFn: mySetupFunction,
middlewareConfigFn: myMiddlewareConfigFn,
},
// ...
})

Setup Function​

setupFn declares a Typescript function that will be executed on server start.

Adding a Custom Route​

As an example, adding a custom route would look something like:

src/myServerSetupCode.js
export const mySetupFunction = async ({ app }) => {
addCustomRoute(app)
}

function addCustomRoute(app) {
app.get("/customRoute", (_req, res) => {
res.send("I am a custom route")
})
}

Storing Some Values for Later Use​

In case you want to store some values for later use, or to be accessed by the Operations you do that in the setupFn function.

Dummy example of such function and its usage:

src/myServerSetupCode.js
let someResource = undefined

export const mySetupFunction = async () => {
// Let's pretend functions setUpSomeResource and startSomeCronJob
// are implemented below or imported from another file.
someResource = await setUpSomeResource()
startSomeCronJob()
}

export const getSomeResource = () => someResource
src/queries.js
import { getSomeResource } from "./myServerSetupCode.js"

...

export const someQuery = async (args, context) => {
const someResource = getSomeResource()
return queryDataFromSomeResource(args, someResource)
}
note

The recommended way is to put the variable in the same module where you defined the setup function and then expose additional functions for reading those values, which you can then import directly from Operations and use.

This effectively turns your module into a singleton whose construction is performed on server start.

For the full description of the setupFn field, check the Server API Reference.

Middleware Config Function​

You can configure the global middleware via the middlewareConfigFn. This will modify the middleware stack for all operations and APIs.

Read more in the configuring middleware section.

Working Directory​

The server runs with your project's root directory as its working directory, both with wasp start and in production. Relative paths in your server code, like fs.readFile("src/data/countries.json") or an uploads/ folder for file uploads, resolve from the project root.

Don't write files into src/ at runtime

wasp start watches your project's src/ folder and top-level files. If your server writes there, wasp start restarts the server or rebuilds your app, and a server that writes into src/ on startup gets stuck in a restart loop. Write files to a subfolder of the project root instead, like uploads/.

In the Docker image that wasp build generates, the project root is /app. The image doesn't include your project's files, so if your server reads any of them at runtime, keep them in src/ and copy them into the image with a custom Dockerfile:

Dockerfile
COPY src/data/ /app/src/data/

Trace Dependencies​

The server's Docker image contains only the files Wasp finds by following the server's imports. If a package loads files in a non-standard way, for example static assets it serves from a folder, list it in traceDeps so Wasp copies those files too.

Read more in the deployment section.

API Reference​

API reference

Server »

All the options for the server field of the app spec.

API reference

ServerSetupFn »

The type of your setupFn function.

API reference

MiddlewareConfigFn »

The type of your middlewareConfigFn function.