Productive development with Site API
summary
A lightweight Site API layer sits on top of the repository API and translates content models into template-ready objects, offering lazy-loaded value objects (content, location, field), Twig-friendly properties like content.name and content.mainLocation, and a set of query types (tag/reverse/children) that run via Solr or the legacy search (find vs filter service). Installation is a Composer bundle with view YAML config, Pagerfanta helpers and controllers removed. It reduces boilerplate (many controller methods disappear), proves faster in real projects (front-end dev finished ~50% of estimated hours) and is production-used and actively maintained.
AI-written summary · about
chapters (30)
- 0:00Start
- 0:57Petar Španja
- 1:45Mario Blažek
- 3:36Similarities with Legacy
- 4:11Differences from Legacy
- 7:27Good sides of the Legacy way
- 7:42Public API
- 8:49An example
- 12:36The missing piece
- 13:15The result
- 17:20The first version
- 18:07LoadService
- 22:56Which is better?
- 24:24Second big update
- 26:53Location
- 27:13Field
- 28:27Third big update
- 29:40Query Types on steroids
- 31:06Use case
- 31:49Legacy Stack way.
- 32:22New Stack way
- 35:56Built-in Query Types
- 36:33Conclusions
- 38:16Recapitulation
- 39:42Why use it?
- 40:03Installation
- 40:25Activation
- 40:42View configuration
- 41:10The main switch
- 41:38Documentation
related talks
26mDeveloping an API without API Platform
48mWriting-wroom and Content Delivery API(..)
31mQuick Site Creation
32mBuilding a dynamic SPA website with Angular
20mComposability: The New Architect in Town
24mDevelopers: write code, not content
32mIntroducing Abell, a New Vite-Powered Static-Site-Generator
32mThe Evolution and Future of Content Publishing