NoEgo Framework

Backend

noego.config.yml

server:
  main: src/server/server.ts
  controllers: src/server/controller
  middleware: src/middleware
  openapi: src/server/stitch.yaml
  watch:
    - src/server/**/*.ts
    - src/middleware/**/*.ts
    - src/server/stitch.yaml
    - src/server/openapi/**/*.yaml

The server block tells App how to start the backend process and how Dinner should resolve route handlers, middleware, and the backend route definitions.

Backend Settings

server.main: Required when the server block is present. This is the backend service entry that App imports after project boot.
server.controllers: Controller lookup root. Dinner uses this to resolve controller names from the backend route definitions.
server.middleware: Middleware lookup root. Dinner uses this to resolve route middleware names from the backend route definitions.
server.openapi: Backend route definitions file. Dinner reads this after the backend service starts.
server.watch: Development restart triggers. Changes matching these patterns restart the backend service while the dev server is running.

server.main

server.main runs in the backend process. Install process-local middleware and then call the backend boot helper.

src/server/server.ts

import express from "express";
import { boot as bootBackend } from "@noego/app/client";

export default async function server(app: express.Express) {
  app.use(express.json({ limit: "50mb" }));

  return bootBackend();
}

server.openapi

server.openapi points Dinner at the backend route definitions. Route definition composition is covered separately in the Stitch configuration section.

Read the Stitch configuration section

server.controllers

server.controllers is the lookup root App gives to Dinner for API controller resolution. Use this setting to choose the root directory; learn the x-controller and x-action mapping rules in the Dinner controller guide.

Where to go next

Dinner owns controller mapping, action dispatch, nested controller paths, and IoC resolution. Read the Dinner controller guide for the route metadata extensions and controller class examples.

Read the Dinner controller guide

server.middleware

server.middleware tells App where Dinner should look for backend route middleware. App owns this path configuration; Dinner owns the x-middleware behavior, export resolution, and execution order.

Where to go next

Use this setting to point at your middleware directory, then read the Dinner middleware guide for route-level declarations, named exports, thin wrapper patterns, and testing guidance.

Read the Dinner middleware guide

server.controllers lifetime

Controllers are normal IoC components. App creates a scoped container for each request, then Dinner resolves the controller from that container. The scope on the controller decides whether the instance is shared or isolated.

Scoped: One controller instance per request scope. Choose this when the controller owns request-specific state or request-scoped collaborators.
Singleton: One shared controller instance. Choose this only when the controller is stateless and delegates all mutable work to injected services.
Transient: A new instance every time the controller is resolved. This is rarely needed, but it is available for explicit per-resolution isolation.

Where to go next

Controller lifetimes use the same scopes as other IoC components. Read the IoC docs for @Component, LoadAs, container scopes, and dependency resolution.

Read the IoC guide

server.watch

server.watch lists backend files that should restart the backend service in development. Include controller, middleware, route definition files, and backend Stitch files so Dinner is rebuilt when route behavior changes.

Stitch Config App Overview Frontend Config