Skip to content

Under the hood:the AntPage platform.

A Laravel delivery API, a Next.js admin, a component design system with its own docs, and a reference website — one monorepo, built to be read by any frontend.

Four parts, one product

  • API

    Laravel CMS & delivery API

    Admin endpoints gated by permission, and a delivery API that returns pages, menus, layouts and route rules already resolved.

  • Admin

    Next.js admin panel

    Twenty-plus screens for pages, types, collections, menus, routes, media, SEO, roles and users — with a server-side API proxy.

  • Design system

    GeekLego components

    Atoms, molecules and organisms, each with a schema, a CMS bridge and fixtures — documented in their own app.

  • Website

    Reference Next.js site

    Resolves every path against the CMS and renders its blocks — the most complete thing built on AntPage.

Architecture

From code to every screen

  1. 1Design system

    Components

    Atoms, molecules and organisms built in code.

    Schemas

    Each component declares the fields an editor may fill.

  2. 2AntPage

    Design Sync

    Schemas become content types, after a reviewed diff.

    Admin

    Pages, menus, routes, media, SEO, roles.

    Content store

    MariaDB, Redis, and S3-compatible media.

  3. 3Delivery

    Delivery API

    Key-gated, resolved pages, menus and route rules.

    Public content API

    Read-only, keyless, described by OpenAPI 3.1.

  4. 4Frontends

    Reference website

    The Next.js site bundled with AntPage.

    This site

    A separate Next.js app with its own components.

    Your app

    Anything that can send an HTTP request.

Design system: 2 parts, then AntPage: 3 parts, then Delivery: 2 parts, then Frontends: 3 parts.

For developers

One request returns the whole page

Ask for a path, get back its fields and every block, already resolved. Render each block by its component key and you are done.

  • Key-gated

    Each frontend presents a delivery key; the browser never sees it.

  • Resolved server-side

    Bindings, relationships and media arrive filled in — no follow-up calls.

  • Cache hints included

    Every response says how long it may be reused.

  • Draft-aware

    A preview token lets an editor see unpublished pages on the real site.

GET/api/delivery/v1/pages?path=/features

{
  "data": {
    "path": "/features",
    "locale": "en",
    "fields": { "title": "Features" },
    "layout": "default",
    "blocks": [
      {
        "label": "Hero Default",
        "root": {
          "type": "component",
          "component": "HeroDefault",
          "instances": [
            {
              "fields": {
                "heading": "Every feature,",
                "headingemphasis": "in detail.",
                "subheading": "What AntPage does for…"
              }
            }
          ]
        }
      },
      …
    ]
  },
  "meta": { "revalidate_after": 30 }
}
200 OK · application/jsonX-Delivery-Key: ••••••

Request lifecycle

What happens when a page is requested

  1. Step 01

    Route rules first

    Redirects and gone-pages from the CMS are checked before anything renders.

  2. Step 02

    Page by path

    The frontend asks the delivery API for the path and locale, presenting its delivery key.

  3. Step 03

    Resolved blocks

    Bindings, relationships and media are resolved server-side; each block names its component.

  4. Step 04

    Render and cache

    The frontend renders each block by key and revalidates on the interval the API suggests.

The stack

  • Laravel 13

    PHP 8.3, Sanctum, Socialite and role-based permissions.

  • Next.js 16

    React 19 and Tailwind CSS 4 across the admin, docs and website.

  • MariaDB & Redis

    Relational content storage, with Redis for cache, sessions and the queue.

  • S3 storage

    Any S3-compatible object store for the media library.

Want the technical tour? Ask the team that built it.

Talk to us