FastAPI assembles the current PostgreSQL content into pages, previews, and search results with a shared presentation.
Redstart uses FastAPI, a Python web framework, to assemble and serve its pages. The site now uses PostgreSQL for its authored content, with Python assembling records into the page and search experiences people use. The database stores the authored content, and Python determines how it appears on a page. An article has one canonical record; the page, card, and search result draw from it. Readers benefit when the title they notice leads to the article it describes and a correction reaches every place that displays the content.
One content record, several useful presentations.
Redstart's site uses FastAPI to assemble published pages, shared navigation, and content records. For a reader, the useful result is a consistent route from a Creative tile to its complete article. FastAPI supports that connection by assembling the page from the same content. A Creative’s title and summary live in its database record, while an associated worked example supplies the detailed scenario. Python reads those records to display the article, its cards, and its search result. Related-lesson links and custom SVG examples also have database-owned records and relationships. Those are current parts of this site, not hypothetical future capabilities.
The site first moved to FastAPI and later moved its authored content into PostgreSQL. The current system should be described as it exists today. A technical choice is useful when it helps keep content accurate, links predictable, and the site manageable. It should not become a substitute for explaining the content itself.
Put it into practice.
To understand how a site delivers content, follow a particular piece of information from storage to the page. Find its authoritative record, the pages and previews that read it, and how a saved change reaches those places. Maintain navigation and presentation rules in the shared code or records that supply them. In this site, creating supported content means writing its complete database records; it does not require making a separate file draft or rebuilding the application for each article. Changes to application behavior remain a different kind of work from ordinary editorial changes.
What does this technical choice make easier for the person using it?