Skip to content
PAM

PAM application skeleton

The push-in/pam-skeleton repository is the versioned source used by PAM to generate a clean API application. Do not clone it for normal development; let the CLI select the release compatible with your runtime.

Start here

Section titled “Start here”

Install and verify PAM first. The runtime then selects the compatible skeleton; the generated HTTP dependency remains an ordinary Composer package:

Terminal window
curl -fsSL https://github.com/push-in/pam/releases/latest/download/install.sh | sh
pam doctor
pam init my-api --template http
cd my-api
pam composer require pushinbr/pam-http
mkdir -p storage && touch storage/database.sqlite
pam composer migrate
pam doctor
pam dev index.php

The server starts at http://127.0.0.1:3000. Set PAM_PORT to select another listener port.

What the generated project contains

Section titled “What the generated project contains”
  • GET /api/ping mapped to [PingController::class, 'show'];
  • a thin controller, readiness service, readonly snapshot and JSON Resource;
  • a sequential integer-backed ReadinessStatus enum;
  • GET /api/products and POST /api/products, mapped to named ProductController methods;
  • a complete Eloquent flow with Form Request, readonly DTO, service, repository, model, migration and JSON Resource;
  • a sequential integer-backed ProductStatus enum (1 active, 2 archived);
  • boot-time typed PAM_PORT validation;
  • security-header middleware;
  • an in-memory application test using the PAM API test client;
  • standard Composer metadata, scripts, autoloading and lockfile behavior.

Create and list persisted products:

Terminal window
curl -X POST http://127.0.0.1:3000/api/products \
  -H 'content-type: application/json' \
  -d '{"name":"Mechanical keyboard","priceInCents":34990}'
curl http://127.0.0.1:3000/api/products

The create action returns 201 Created. Validation stays in StoreProductRequest, the use case stays in ProductService, persistence stays behind ProductRepository, and ProductResource owns the representation. Migrations are explicit rather than part of HTTP worker boot, so concurrent production workers cannot race schema changes. Re-running pam composer migrate is safe and reports when the database is already current.

The CLI embeds these canonical skeleton files at build time. CI generates a fresh project, performs a Composer dry-run, installs the local PAM API 2.0 candidate and executes the ping plus SQLite/Eloquent endpoint tests inside the Embed SAPI, preventing the published skeleton and pam init output from drifting apart.

HTTP and skeleton releases are intentionally ordered. PAM HTTP 2.0.1 has passed its public Packagist installation gate. Every subsequent skeleton release must repeat the clean-consumer dry-run and installation proof; the native PAM runtime does not need a matching package major version.

Daily workflow

Section titled “Daily workflow”
Terminal window
pam dev index.php
pam test
pam composer test
pam doctor
pam info --json

pam dev index.php runs the persistent server with hot reload. pam test selects contextual project tests, while pam composer test explicitly invokes the Composer script. pam info --json exposes machine-readable project discovery for tooling and CI.

Add capabilities

Section titled “Add capabilities”
Terminal window
pam init realtime-api --template http --socket
pam composer require pushinbr/pam-native-observability
pam doctor

Use Packagist to discover packages. PAM exposes Composer without introducing a second manifest, registry or lockfile.

Release checklist

Section titled “Release checklist”
Terminal window
pam release --check
pam package

Configure listener limits, trusted proxies and TLS termination; exercise error, timeout and shutdown paths; keep secrets outside version control; and test the packaged artifact in its target environment.