mirror of
https://github.com/Stirling-Tools/Stirling-PDF.git
synced 2026-09-03 05:10:16 +03:00
## What
Lets the admin portal ("Stirling Processor") ship **inside the JAR**,
gated by a build flag. On `main` the portal already exists as a lazy
`/portal/*` route in the editor but isn't included in production builds
and isn't reachable in a login-enabled server. This PR makes it a
**flag-gated, directly-navigable** part of the editor bundle, and wires
it into the PR preview deployment so it can be tried live.
It keeps the exact architecture `main` uses (portal = a lazy chunk of
the editor, not a separate app), so it inherits all the editor's global
providers/styles and there's no second build to maintain.
## How
**Frontend - gate the existing lazy route**
([`adminRouteExtensions.tsx`](frontend/editor/src/proprietary/routes/adminRouteExtensions.tsx))
```ts
const includePortal = import.meta.env.VITE_INCLUDE_PORTAL === "true" || import.meta.env.DEV;
const PortalApp = includePortal ? lazy(() => import("@portal/PortalApp")) : null;
```
Vite bakes the env to a literal, so when off the dynamic import is
**tree-shaken out entirely** (no `PortalApp` chunk emitted). Always on
in dev. `VITE_INCLUDE_PORTAL` is typed in `vite-env.d.ts` and declared
(default `false`) in `editor/.env`.
**Gradle** ([`build.gradle`](app/core/build.gradle)) -
`-PbuildWithPortal=true` forces `buildWithFrontend=true` and sets
`VITE_INCLUDE_PORTAL=true` on the editor build. Process-env takes
priority over `.env`, so the flag wins for JAR builds while plain `vite
build` / Cloudflare Pages default to off.
**Backend - make the shell reachable**
([`RequestUriUtils`](app/common/src/main/java/stirling/software/common/util/RequestUriUtils.java))
- permits `/portal` + `/portal/*` as public SPA routes. The editor keeps
its JWT in localStorage (not a cookie), so a direct nav/refresh to
`/portal` isn't authenticated at the server and would otherwise redirect
to `/login` and never load. Serving the shell pre-auth (like the editor
root already is) lets it load; **access control is unchanged** - the
portal has its own auth gate + `RequirePortalAccess`, and its data APIs
stay protected.
**Docker** - the embedded Dockerfiles take `ARG BUILD_PORTAL=false` →
`-PbuildWithPortal=${BUILD_PORTAL}`. Default off, so official
`push-docker` images do **not** bundle the portal.
**CI - scoped to the PR preview deploy only**
([`PR-Auto-Deploy-V2.yml`](.github/workflows/PR-Auto-Deploy-V2.yml)) -
the one job that builds the JAR and comments owns all portal wiring:
passes `BUILD_PORTAL=true`, enables the portal's backend features
(`POLICIES_ENABLED`, `STIRLING_BILLING_ACCOUNT_LINK_ENABLED`), and adds
an "Admin portal included" line (linking `/portal` via the direct IP) to
the deployment comment. `push-docker`, `build.yml`, `test-build-docker`,
and the shared paths-filter are untouched.
## Validation (real, in the JAR)
Built and booted the JAR with `-PbuildWithPortal=true` and login
enabled:
- `/portal` and `/portal/users` load via direct nav and render **fully
themed** (dark surfaces, gradients, filled buttons).
- Editor-only build (`-PbuildWithFrontend=true`, no portal flag) →
editor ships, **0 portal chunks** (tree-shaken).
- `-PbuildWithPortal=true` → `PortalApp` chunk present.
Green: `frontend:check:all` (typecheck all variants, lint, format,
build, tests incl. the `VITE_*` env guard), backend compile,
`RequestUriUtilsTest`, spotless.
## Notes
- **Official images never bundle the portal** (Dockerfile default off);
only the PR preview does. Flip `BUILD_PORTAL` / `-PbuildWithPortal` to
include it elsewhere.
- The `/portal` shell being public is the one deviation from `main`, and
it's required for the route to be reachable at all in a login-enabled
server; data access is still fully gated.
Docker Setup for Stirling-PDF
This directory contains the organized Docker configurations for the split frontend/backend architecture.
Using Taskfile (Recommended)
All Docker commands can be run from the project root using Task:
task docker:build # Build standard image
task docker:build:fat # Build fat image (all features)
task docker:build:ultra-lite # Build ultra-lite image
task docker:build:frontend # Build frontend-only image
task docker:build:engine # Build engine image
task docker:up # Start standard compose stack
task docker:up:fat # Start fat compose stack
task docker:up:ultra-lite # Start ultra-lite compose stack
task docker:down # Stop all running stacks
task docker:logs # Tail compose logs
Directory Structure
docker/
├── backend/ # Backend Docker files
│ ├── Dockerfile # Standard backend
│ ├── Dockerfile.ultra-lite # Minimal backend
│ └── Dockerfile.fat # Full-featured backend
├── frontend/ # Frontend Docker files
│ ├── Dockerfile # React/Vite frontend with nginx
│ ├── nginx.conf # Nginx configuration
│ └── entrypoint.sh # Dynamic backend URL setup
└── compose/ # Docker Compose files
├── docker-compose.yml # Standard setup
├── docker-compose.ultra-lite.yml # Ultra-lite setup
└── docker-compose.fat.yml # Full-featured setup
Usage
Separate Containers (Recommended)
From the project root directory:
# Standard version
docker-compose -f docker/compose/docker-compose.yml up --build
# Ultra-lite version
docker-compose -f docker/compose/docker-compose.ultra-lite.yml up --build
# Fat version
docker-compose -f docker/compose/docker-compose.fat.yml up --build
Access Points
- Frontend: http://localhost:3000
- Backend API (debugging): http://localhost:8080 (TODO: Remove in production)
- Backend API (via frontend): http://localhost:3000/api/*
Configuration
- Backend URL: Set
VITE_API_BASE_URLenvironment variable for custom backend locations - Custom Ports: Modify port mappings in docker-compose files
- Memory Limits: Adjust memory limits per variant (2G ultra-lite, 4G standard, 6G fat)
Google Drive Integration
- VITE_GOOGLE_DRIVE_CLIENT_ID: OAuth 2.0 Client ID
- VITE_GOOGLE_DRIVE_API_KEY: Create New API
- VITE_GOOGLE_DRIVE_APP_ID: This is your project number in the GoogleCloud Settings
Development vs Production
- Development: Keep backend port 8080 exposed for debugging
- Production: Remove backend port exposure, use only frontend proxy