Why Pionia?

Who this is for

You are choosing a PHP framework for Pionia Shop’s Pionia Shop — or any mobile/SPA backend — and want to know whether Moonlight’s { service, action } model beats dozens of REST controllers.

What you will learn

  • What Pionia optimizes for (versioned JSON APIs, small teams)
  • How Pionia Shop maps to services, switches, and Porm queries
  • When to pick something else (server-rendered HTML, GraphQL-first)

Before you start

No install required. For a hands-on comparison, scaffold Pionia Shop in Introduction first.

How it works

Pionia targets teams shipping versioned JSON APIs without Symfony-sized boilerplate. You write services and register them on switches; clients POST { "service", "action" } to http://127.0.0.1:8000/api/v1/.

Pionia Shop example

Pionia Shop is a fictional online store + wallet — the app you build in the tutorial.

Pionia Shop — a fictional online store + wallet. Services: product, customer, order, wallet. Sample customer: ada@pionia.shop.

What you get

  1. Services, not controllers — business logic lives in services/ProductService.php. Moonlight dispatch replaces per-route controllers.
  2. Porm, not ORMtable('products')->filter(...)->all() returns arrays; no model hydration overhead. See Database.
  3. Real HTTP semantics — validation errors are 422, auth failures 401; the JSON body still uses returnCode. See Requests & responses.
  4. Versioned switches — add v2 in settings.ini without rewriting v1. See API versioning.
  5. Flexible auth — pluggable backends and per-action checks. See Security.
  6. Optional Vite SPA — scaffold React/Vue beside the API. See Frontend integration.
  7. Production workers — RoadRunner, OPcache preload, maintenance mode. See Operations.

When Pionia fits

Good fitLess ideal
Mobile or SPA backends with stable JSON contractsServer-rendered HTML as the primary UI
Small teams who want one envelope shapeGraphQL-first APIs
CRUD plus custom actions on the same switchPlugin-heavy CMS-style admin

Moonlight in one paragraph

Moonlight is the { service, action } contract: one POST target per API version, predictable JSON envelopes, and switches that map aliases to PHP classes. Pionia implements that contract with real HTTP status codes, OpenAPI export, and first-class tooling.

Common mistakes

  • Expecting Laravel-style Eloquent models — Porm queries tables directly; there is no built-in ORM layer.
  • Treating Moonlight as RPC over HTTP 200 only — v3 uses real status codes for auth and validation failures.
  • Choosing Pionia for a Blade-only admin site — you can, but server-rendered HTML is not the sweet spot.

What’s next

Pionia Shop tutorial

Build Pionia Shop hands-on.

Moonlight overview

Architecture deep dive.

Upgrading from v2

Migration checklist.