README
¶
ShopFront: the declaration-driven flagship
This is the largest example in the repo and the proof of the framework's
thesis: a complete storefront described once in
gofastr.yml: 5 related entities (categories, products,
orders, order_items, reviews), a themed 8-screen UI, custom endpoints,
seed data, middleware, and a plugin, all emitted as runnable Go by a
single command. Nothing under app/ is hand-written.
What it proves
One blueprint fans out into every surface: auto-migrated SQL schema,
REST CRUD with validation and cursor pagination, OpenAPI, 25 MCP tools
for agents, and a server-rendered themed storefront. All of it is
asserted live by flagship_test.go, which
regenerates app/ from the blueprint, builds the binary, boots it, and
hits each surface, so the proof never depends on a stale checkout.
Secure by default
The blueprint ships with auth enabled (app.auth.enabled: true) and the
customer-PII entities, orders and order_items, owner-scoped via
owner_field: user_id. The framework stamps the owner on create and
scopes every list/get/update/delete (REST and MCP) to the requesting
user, failing closed with 401 when no owner can be derived.
TestOrdersOwnerScoped pins this. (The first cut shipped insecure;
git history has the full story of the fix.)
Regenerate and run
cd examples/ecommerce
gofastr generate --from=gofastr.yml --force # re-emits app/ from the blueprint (output_dir: app)
gofastr dev --dir app # hot-reload dev server on localhost:8080
app/ is committed, owned Go. output_dir: app in the blueprint puts the
app in a subpackage so the example also hosts its own test files.
Read next
flagship_test.go: the end-to-end proof.gofastr.yml: the entire input.
Documentation
¶
Overview ¶
Package ecommerce is GoFastr's declaration-driven flagship example: a complete storefront: five related entities, screens, navigation, custom endpoints, seed data, and a theme, declared once in gofastr.yml and emitted as runnable Go by the CLI:
gofastr generate --from=gofastr.yml
The generated app is committed under app/ (output_dir: app in the blueprint) and is the proof of the framework's thesis: one blueprint produces a SQL schema, REST CRUD, an OpenAPI spec, a typed MCP tool surface, and a server-rendered UI, none of it hand-written. flagship_test.go regenerates app/ with --force on every run and blueprint_gate_test.go fails when the committed files differ from what the in-tree generator emits, so app/ can never drift from the CLI.
Run it directly:
go run ./examples/ecommerce/app
Source Files
Directories