DEV Community: César Zoleko

# Serving React as Static Files from NestJS — Te Underrated Production Pattern

César Zoleko — Sat, 18 Apr 2026 16:33:20 +0000

Most tutorials about NestJS and React (or Vue, Angular, Svelte — pick your SPA) assume you'll deploy them separately: a Node server for the API, a CDN or Nginx for the frontend, maybe a reverse proxy gluing them together. That setup works fine, but it comes with real operational overhead — two services to monitor, two deploy pipelines to maintain, and a whole category of bugs that only exist because your frontend and backend live on different origins.

There's a simpler path. NestJS can serve your compiled SPA as static files, making the whole thing a single deployable unit. It's not widely discussed, and I think it deserves more attention.

Quick note on scope: this pattern works with any Single Page Application — React, Vue 3, Angular, Svelte, SolidJS, you name it. The moment your framework's build step produces a static dist/ folder (which they all do), NestJS can serve it. I'll use React + Vite throughout this article as a concrete example, but every concept applies directly to any other SPA.

What "serving static files" actually means here

When you run npm run build on any modern SPA (React, Vue, Angular, Svelte…), you get a dist/ folder containing index.html, bundled JS, CSS, and assets. That's it — no server required. Any HTTP server capable of serving files can host it.

NestJS ships with @nestjs/serve-static, a module that turns your NestJS app into exactly that kind of server. You point it at your build output, and NestJS handles the rest: serving index.html for unknown routes (client-side routing support), caching headers, MIME types, everything.

The result: one process, one port, one deployment.

Browser
  │
  ▼
NestJS (port 4200)
  ├── /api/*    → NestJS controllers (your REST API)
  └── /*        → React static files (index.html + assets)

Setting it up

1. Install the module

npm install @nestjs/serve-static

2. Configure the React build output

With Vite, point the build output directly into your NestJS project so the compiled app is always in the right place:

// front-app/vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import path from 'path'

export default defineConfig({
  plugins: [react()],
  build: {
    outDir: path.resolve(__dirname, '../back-app/client'),
    emptyOutDir: true,
  },
})

3. Register ServeStaticModule in NestJS

// app.module.ts
import { Module } from '@nestjs/common'
import { ServeStaticModule } from '@nestjs/serve-static'
import { join } from 'path'

@Module({
  imports: [
    ServeStaticModule.forRoot({
      rootPath: join(__dirname, '..', 'client'),
      renderPath: '/*',       // serve index.html for any unmatched route
      exclude: ['/api/(.*)'], // keep /api/* routed to controllers
    }),
    // ... your other modules
  ],
})
export class AppModule {}

4. Prefix all your API routes

This is the critical step. Every NestJS controller must live under a common prefix so it never conflicts with static file serving:

// main.ts
async function bootstrap() {
  const app = await NestFactory.create(AppModule)

  app.setGlobalPrefix('api')

  await app.listen(4200)
}
bootstrap()

Your React app then calls /api/orders, /api/products — same origin, no CORS needed.

5. Development workflow — keep Vite's HMR

You still want two separate processes during development. Vite's HMR is too valuable to give up. Run NestJS on port 4200 and Vite on port 3000, with Vite proxying /api requests to the backend:

// vite.config.ts (dev only)
export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:4200',
        changeOrigin: true,
      },
    },
  },
})

In development, Vite serves the frontend. In production, NestJS serves the compiled output. The code itself — every fetch('/api/...') call — stays identical.

The advantages that actually matter in production

Same-origin requests — cookies and CSRF just work

This is the biggest win and the one most people overlook.

When your frontend and backend share the same origin (https://yourdomain.com), cookies are sent automatically with every request. Session-based authentication, CSRF double-submit patterns, SameSite: strict cookies — all of it works without any extra configuration.

With a split deployment you need to:

Configure CORS (Access-Control-Allow-Origin, credentials: true)
Align cookie domains and SameSite policies across origins
Set credentials: 'include' on every fetch call
Accept that SameSite: strict is off the table

Each one of these is a potential footgun. A concrete example: in a session + CSRF setup (like csrf-csrf), the token validation ties the CSRF token to the session ID. With same-origin, the session cookie arrives with every request automatically. With cross-origin, you're one misconfigured allowedOrigins away from a 403 in production that only manifests after a page refresh.

One service to deploy and monitor

A typical split setup means:

Two Docker images, two build pipelines
Two services in docker-compose.yml or Kubernetes manifests
A reverse proxy (Nginx, Traefik) sitting in front of both
Logs and metrics spread across multiple services

With the unified approach:

# docker-compose.yml — that's the whole file
services:
  app:
    build: .
    ports:
      - "4200:4200"
    environment:
      - NODE_ENV=production
      - DATABASE_URL=${DATABASE_URL}

One image. One service. One set of logs. One health check endpoint.

A clean multi-stage Dockerfile

FROM node:20-alpine AS frontend-build
WORKDIR /app/front-app
COPY front-app/package*.json ./
RUN npm ci
COPY front-app/ .
RUN npm run build
# Vite outputs to ../back-app/client (configured in vite.config.ts)

FROM node:20-alpine AS backend-build
WORKDIR /app/back-app
COPY back-app/package*.json ./
RUN npm ci
COPY back-app/ .
COPY --from=frontend-build /app/back-app/client ./client
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=backend-build /app/back-app/dist ./dist
COPY --from=backend-build /app/back-app/client ./client
COPY --from=backend-build /app/back-app/node_modules ./node_modules
COPY back-app/package.json .

EXPOSE 4200
CMD ["node", "dist/main"]

No Nginx config. No reverse proxy. The Node process handles everything.

No environment-specific frontend builds

In a split deployment, your React app needs to know the API URL at build time — a VITE_API_URL env variable baked into the bundle. That URL must match wherever you actually deployed the backend. Get it wrong and you're shipping a build that points at the wrong server, or worse, at localhost.

With unified serving, the API is always at the same origin. No VITE_API_URL to manage:

// same line, every environment — staging, preprod, production
const response = await fetch('/api/orders')

The same build artifact works everywhere. No environment-specific rebuilds.

Static asset caching with Vite's content hashes

Vite hashes all asset filenames by default (main.a3f2b1.js). This means you can apply aggressive caching headers safely — browsers will only re-fetch when the content actually changes:

ServeStaticModule.forRoot({
  rootPath: join(__dirname, '..', 'client'),
  serveStaticOptions: {
    setHeaders: (res, filePath) => {
      if (/\.(js|css|png|jpg|svg|woff2)$/.test(filePath)) {
        res.setHeader('Cache-Control', 'public, max-age=31536000, immutable')
      }
    },
  },
}),

index.html gets no cache header (or a short one), so deployments propagate immediately while assets stay cached on the client indefinitely.

When to use it — and when not to

Scenario	Recommendation
Single NestJS app + single React frontend	✅ Unified serving
Session-based auth or strict CSRF	✅ Unified serving (same-origin is a hard win)
Small to medium team, monolith deployment	✅ Unified serving
Multiple frontend apps sharing the same backend	❌ Split deployment
Frontend needs global CDN edge caching	❌ Split deployment
Microservices backend	❌ Split deployment
Independent scaling of frontend and backend	❌ Split deployment

Why you don't see this pattern often

The industry default of "separate everything" made sense when teams were large, traffic was high, and independent scaling was a priority from day one. That mindset spread, became the tutorial default, and stuck.

There's also a perception issue: serving static files from an API server feels wrong to people who think of Node as "not a real web server." That mental model is outdated. Node handles static file serving perfectly well for the vast majority of projects, and @nestjs/serve-static is built exactly for this use case.

The result is that a genuinely useful, operationally simple pattern gets overlooked in favour of more complex setups that most projects don't need.

Closing thoughts

Serving React from NestJS removes an entire class of cross-origin problems, collapses your deployment to a single container, and makes local-to-production parity easy to maintain. The @nestjs/serve-static module handles the hard parts. The rest is pointing it at a dist/ folder.

It's not the flashiest architecture. In production, that's usually the point.

Have you tried this pattern in a real project? Curious about the tradeoffs you ran into — drop a comment below.

Tags: #nestjs #react #vue #angular #spa #typescript #webdev #nodejs #devops #javascript

Dynamic forms with discriminatedUnion and React Hook Form

César Zoleko — Thu, 19 Dec 2024 11:41:44 +0000

Form validation is a crucial aspect of modern web applications. With libraries such as React Hook Form (RHF) and Zod, you can efficiently validate dynamic forms, including those with complex structures such as payment methods. This article explains how to use both Zod and RHF to validate forms dynamically using the powerful discriminatedUnion.

What is a discriminatedUnion?

A discriminatedUnion is an advanced typing technique used to model objects with different structures but sharing a common discriminating field. This discriminant field is used to identify which subtype is being used and to perform validation or manipulation accordingly.
For example, consider a payment form that may contain three types of payment method:

Credit card (requires a card number and CVV)
PayPal (requires an email address)
Bank transfer (requires an account number and bank code). Each of these types can be modelled using a discriminatedUnion Example of Data Modelling with Zod

import * as zod from "zod"

const IsNotEmptyString = (message: string) => zod.string({message}).min(1, {message})


export enum PaymentMethodEnum {
   CREDIT_CARD ="creditCard", 
   PAYPAL = "paypal", 
   BANKTRANSFER ="bankTransfer"
}

  const creditCardSchema = zod.object({
   type: zod.literal(PaymentMethodEnum.CREDIT_CARD),
   cardNumber: zod.string().regex(/^\d{16}$/, "The card number must contain 16 digits"),
   cvv: zod.string().regex(/^\d{3}$/, "The Card Validation Code must contain 3 digits"),
 })

 const paypalSchema =  zod.object({
   type: zod.literal(PaymentMethodEnum.PAYPAL),
   email: zod.string().email("PayPal email is invalid"),
 })

 const bankTransferSchema =  zod.object({
   type: zod.literal(PaymentMethodEnum.BANKTRANSFER),
   accountNumber: IsNotEmptyString("The account number must contain at least 10 characters"),
   bankCode: IsNotEmptyString("The bank code must contain at least 4 characters")
 })

export const paymentMethodSchema =  () => zod.discriminatedUnion("type",[
   creditCardSchema, paypalSchema,bankTransferSchema
]); 

export type PaymentMethodSchemaType = zod.infer < ReturnType <typeof paymentMethodSchema>>

How does validation work?

discriminatedUnion inspects the type field:
- If type is ‘creditCard’, Zod validates according to the constraints defined in the first object.
- If type is ‘paypal’, it checks only the rules linked to the PayPal object.
- If type is ‘bankTransfer’, it validates according to the bank transfer criteria.
Strict validation :
- Each type is independent. If a user provides an invalid type or omits a required field, Zod triggers a specific error.
Simplicity for React Hook Form:
- The schema allows RHF to dynamically adapt validation according to the type field, simplifying the logic in the form.

Why use a discriminatedUnion here?

Clear separation of responsibilities
- Each payment method specific rules that must not interfere with each other interfere.
Flexibility
- Allows new types (e.g. a new payment method) to be added easily. types (for example, a new payment method).
Security
- Ensures that any invalid values are detected at validation time.

Integration with React Hook Form

**
React Hook Form makes it easy to manage forms while remaining high-performance and flexible. Here's how to integrate Zod and RHF to validate a form based on discriminatedUnion.

import { useForm, SubmitHandler, FieldErrors } from 'react-hook-form';
import { zodResolver } from '@hookform/resolvers/zod';
import './payment.css';
import {
  PaymentMethodEnum,
  paymentMethodSchema,
  PaymentMethodSchemaType,
} from '../validators/validate-payment-schema';

const Payment = () => {
  const form = useForm<PaymentMethodSchemaType>({
    resolver: zodResolver(paymentMethodSchema()),
    defaultValues: {
      type: PaymentMethodEnum.CREDIT_CARD,
    },
  });

  const { register, formState, handleSubmit } = form;

  const { errors } = formState;

  const paymentType = form.watch().type;

  const handleChangePaymentType = (type: PaymentMethodEnum) => {
    form.setValue('type', type);
  };

  const handleResetForm = () => {
    form.reset(getDefaultFormState(paymentType));
  };

  const onSubmit: SubmitHandler<PaymentMethodSchemaType> = (data) => {
    console.log('data', data);
  };

  const PaymentTypeFormNode: React.ReactNode = (() => {
    switch (paymentType) {
      case PaymentMethodEnum.BANKTRANSFER:
        const bankTransferErrors = getErrorsByPaymentType(errors, paymentType);

        return (
          <div>
            <div className="form">
              <label>Account number</label>
              <input
                {...register('accountNumber')}
                placeholder="Enter your account number"
              />
              {bankTransferErrors?.accountNumber?.message && (
                <span className="errormessage">
                  {bankTransferErrors.accountNumber.message}
                </span>
              )}
            </div>

            <div className="form">
              <label>Bank code</label>
              <input
                {...register('bankCode')}
                placeholder="Enter your bank code"
              />
              {bankTransferErrors?.bankCode?.message && (
                <span className="errormessage">
                  {bankTransferErrors.bankCode.message}
                </span>
              )}
            </div>
          </div>
        );

      case PaymentMethodEnum.CREDIT_CARD:
        const creditCardErrors = getErrorsByPaymentType(errors, paymentType);
        return (
          <div>
            <div className="form">
              <label>Card Number</label>
              <input
                {...register('cardNumber')}
                placeholder="Enter your card number"
              />
              {creditCardErrors?.cardNumber && (
                <span className="errormessage">
                  {creditCardErrors.cardNumber.message}
                </span>
              )}
            </div>

            <div className="form">
              <label>CVV</label>
              <input
                {...register('cvv')}
                placeholder="Enter your card validation code"
              />
              {creditCardErrors?.cvv && (
                <span className="errormessage">
                  {creditCardErrors.cvv.message}
                </span>
              )}
            </div>
          </div>
        );

      case PaymentMethodEnum.PAYPAL:
        const paypalErrors = getErrorsByPaymentType(errors, paymentType);
        return (
          <div className="form">
            <label>Email</label>
            <input
              type="email"
              {...register('email')}
              placeholder="Enter your email"
            />
            {paypalErrors?.email?.message && (
              <span className="errormessage">{paypalErrors.email.message}</span>
            )}
          </div>
        );

      default:
        throw new Error(
          'Exhaustive Guard Error : received value' + paymentType
        );
    }
  })();

  return (
    <form className="form-wrapper" onSubmit={handleSubmit(onSubmit)}>
      <div className="form" style={{ marginBottom: '1rem' }}>
        <label>Type de paiement</label>
        <select
          value={paymentType}
          onChange={(e) =>
            handleChangePaymentType(e.target.value as PaymentMethodEnum)
          }
          style={{ display: 'block', marginTop: '0.5rem' }}
        >
          <option value="creditCard">Credit Card</option>
          <option value="paypal">PayPal</option>
          <option value="bankTransfer">Bank Transfer</option>
        </select>

        <span className="icon">
          <svg
            xmlns="http://www.w3.org/2000/svg"
            width="10"
            height="6"
            viewBox="0 0 10 6"
          >
            <path
              id="Tracé_532"
              data-name="Tracé 532"
              d="M295.717,353.232a.725.725,0,0,1,1.063,0,.8.8,0,0,1,.163.256.834.834,0,0,1,0,.606.8.8,0,0,1-.163.256l-4.248,4.418a.726.726,0,0,1-1.064,0l-4.248-4.418a.8.8,0,0,1-.163-.256.834.834,0,0,1,0-.606.8.8,0,0,1,.163-.256.725.725,0,0,1,1.063,0L292,356.856Z"
              transform="translate(-287 -353)"
              fill="#333"
            />
          </svg>
        </span>
      </div>

      {PaymentTypeFormNode}

      <div style={{ display: 'flex', gap: 20 }}>
        <button type="button" onClick={handleResetForm}>
          Cancel
        </button>
        <button type="submit" className="submit-btn">
          Submit
        </button>
      </div>
    </form>
  );
};

export default Payment;

function getErrorsByPaymentType<T extends PaymentMethodSchemaType['type']>(
  errors: FieldErrors<PaymentMethodSchemaType>,
  _type: T
): FieldErrors<Extract<PaymentMethodSchemaType, { type: T }>> | null {
  return errors as FieldErrors<Extract<PaymentMethodSchemaType, { type: T }>>;
}

const bankTransferDefault: Extract<
  PaymentMethodSchemaType,
  { type: PaymentMethodEnum.BANKTRANSFER }
> = {
  accountNumber: '',
  bankCode: '',
  type: PaymentMethodEnum.BANKTRANSFER,
};

const paypalDefault: Extract<
  PaymentMethodSchemaType,
  { type: PaymentMethodEnum.PAYPAL }
> = {
  email: '',
  type: PaymentMethodEnum.PAYPAL,
};

const creditCardDefault: Extract<
  PaymentMethodSchemaType,
  { type: PaymentMethodEnum.CREDIT_CARD }
> = {
  cardNumber: '',
  cvv: '',
  type: PaymentMethodEnum.CREDIT_CARD,
};

const defaultValue = [creditCardDefault, paypalDefault, bankTransferDefault];

const getDefaultFormState= (type: PaymentMethodEnum) => {
  return defaultValue.find(
    (item) => item.type === type
  ) as PaymentMethodSchemaType;
};

Conclusion

**
So that's it folks. I hope you found this article helpful. discriminatedUnion is a utility type that can be used in many ways. If you think there are more ways to use discriminatedUnion, please let me know in the comments. Thanks for reading this article. See you all in my next article🐸.

test application link:
https://stackblitz.com/edit/vitejs-vite-ppgw9zrb?file=src%2Fpages%2Fpayments.tsx