- architecture: introduction, Go modules and workspaces, application lifecycle, request lifecycle - plugins: registration, scheduling, extending, testing - verified Examples for backpack services, towel request context, pact schedules and festival events - TestDocsRequiredPages lists the eight new pages
3.7 KiB
title, description, section, order
| title | description | section | order |
|---|---|---|---|
| Architecture introduction | How a SummerCMS application is built: one Go binary with compiled plugins, a headless JSON API, an embedded admin SPA and console commands. | architecture | 10 |
Architecture introduction
A SummerCMS application is one Go binary. The framework modules, the application's plugins, the embedded admin SPA and every console command are compiled into it. You deploy that file and its config/ directory; nothing is installed or loaded at runtime.
One binary, compiled plugins
A plugin is a Go package that implements party.Plugin and registers itself from init with party.Register. The application lists the plugins it uses in its summer.yaml manifest. summer build reads that manifest, generates plugins.gen.go (a blank import for every plugin and the ordered PluginIDs list) and a main.go, then runs go build. Adding or removing a plugin is a rebuild, not a runtime switch.
This replaces the WinterCMS plugin directory scan. The compiler checks every plugin against the interfaces it claims to implement, and a missing dependency fails the build or the boot, never a later request.
Headless by design
SummerCMS serves a JSON API and the admin SPA. It has no themes, CMS pages or frontend components: the public site is a separate application that calls the API and subscribes to realtime channels. The admin is a compiled Vue application that boardwalk serves from the binary, and it reads the admin API that cabana builds from each plugin's fields.yaml and columns.yaml.
The framework modules
Each framework module is one Go package under modules/, documented by its README and its API reference page.
| Concern | Modules |
|---|---|
| Plugins and the container | party, pact, backpack, festival, compass |
| HTTP | surf, towel, wire, bouncer, wristband, fetchguard |
| Data | lagoon, beachcomber |
| Admin | cabana, boardwalk |
| Services | phrasebook, postcard, conga, lighthouse, flare |
| Console and tooling | bonfire, tide |
What runs where
Two programs carry console commands:
- The
summertool is the developer CLI. You install it once withgo install ./cmd/summer. It builds and watches applications (summer build,summer dev), scaffolds plugins and their parts (summer make:plugin,summer make:modeland the othermake:commands), records and replays API parity fixtures and builds these docs. - The application binary, for example
bin/hello, carries the runtime commands:serve,migrate,route:list,queue:work,admin:createand the commands its plugins add. It is what you run in production.
Some summer commands, such as summer migrate and summer serve, run the matching command of the application binary in the current application directory, building it first when it is missing. The Installation guide walks through both programs.