Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/reds-skywalker/Lightpress/llms.txt

Use this file to discover all available pages before exploring further.

The client/ directory contains the user-facing web application for Lightpress. It is a standalone Node.js frontend project that connects to your microservices over HTTP, handles authentication flows, and delivers the interface your end users interact with. Because it is decoupled from the backend, you can iterate on the UI without touching any service logic, and deploy it independently to a CDN or container host.

​
Directory structure

client/
├── src/
│   ├── components/    # Reusable UI components
│   ├── pages/         # Page-level components / routes
│   └── services/      # HTTP API call wrappers
├── package.json
├── .env.example
└── Dockerfile
The services/ layer inside the client is where API calls to each microservice are organized. Keep HTTP logic here rather than scattering fetch calls across components — it makes it straightforward to swap base URLs between local and production environments.

​
Tech stack

Lightpress uses a JavaScript/TypeScript frontend. The .gitignore excludes node_modules, dist, and build, which matches the output conventions of the major React-based frameworks.

​
Connecting to microservices

The client talks to the microservices backend over HTTP/HTTPS. In local development, each service exposes a port via Docker Compose. In production, requests go through an Application Load Balancer (ALB) that routes to each service by path prefix. 
const BASE_URL = process.env.NEXT_PUBLIC_API_URL ?? 'http://localhost:4000';

export async function getUser(id: string) {
  const res = await fetch(`${BASE_URL}/users/${id}`, {
    headers: { Authorization: `Bearer ${getToken()}` },
  });
  if (!res.ok) throw new Error(`Failed to fetch user: ${res.status}`);
  return res.json();
}
Never hard-code service URLs in component files. Always read from environment variables so the same build artefact can target different environments without modification.

​
Local development workflow

1

Start all services with Docker Compose

From the repository root, bring up the full stack. This starts the client dev server alongside every microservice.
docker compose up --build
2

Or run the client standalone

If you only need to work on the UI and the backend services are already running (or you are mocking them), start just the client.
# Inside client/
npm install
npm run dev
3

Set environment variables

Copy the example env file and point NEXT_PUBLIC_API_URL at your local or remote microservices.
cp .env.example .env.local
# Edit .env.local
4

Verify service connections

Open the running app in your browser and confirm that data loads from the backend. Check the browser network tab — requests should resolve to your local service ports.

​
Building for production

The client/Dockerfile produces an optimized production image. The Docker Compose file and CodeBuild pipeline use this same image.
docker build -t lightpress-client ./client
docker run -p 3000:3000 \
  -e NEXT_PUBLIC_API_URL=https://api.yourdomain.com \
  lightpress-client
The dist/ and build/ directories are in .gitignore and are never committed. Always build artefacts in CI (via buildspec.yml) rather than committing compiled output.

​
Environment variables

VariableDescription
NEXT_PUBLIC_API_URLBase URL for microservices API (ALB URL in production)
NEXT_PUBLIC_APP_ENVCurrent environment: development, staging, or production
VariableDescription
NEXT_PUBLIC_AUTH_URLOverride for the authentication service endpoint
NEXT_PUBLIC_SENTRY_DSNSentry DSN for frontend error tracking
Keep a .env.example file in client/ committed to the repository with all variable names but no values. New developers copy this file to .env.local as part of onboarding.

Build docs developers (and LLMs) love

Get started for freeTalk to us