Web development
A web base to reuse: Astro, FastAPI and a custom dashboard
My first project in Astro, after years with WordPress: a base
2 min read
The first project in Astro
Until now I've worked with WordPress: that was where I built the websites for my projects and those of my clients. This is the first project I start from scratch with Astro (a modern web generator), and it's not a technical whim: it's an investigation, as I explained in Rebuilding Pànxing from scratch. I want to test on the ground what it's like to work with Astro, FastAPI (the Python framework), PostgreSQL (the database) and AI agents, before committing to it.
Why a base
I start web projects often and I always repeat the same thing: public website, admin panel, authentication (verifying who you are) and deployment (putting the site on the server). This time I've decided to do it once and do it right: a custom base, solid and designed to be reused.
The starting point
Yesterday I set up the first version: Astro with the Lumos framework, FastAPI and SQLite (a simple database, in a single file). It worked, but I soon saw that it would fall short of what I want: multiple users, vector search (searching by meaning), AI integration and agents. This morning I've started a deep refactoring, before adding anything new.
Where it's going
The base has already taken a turn: PostgreSQL with pgvector (the vector search extension), migrations with Alembic (the tool that evolves the data structure), fully dockerised (containers that run the same everywhere), JWT authentication (session credentials) with automatic renewal, and the backend separated into services and repositories. The dashboard is being migrated screen by screen, and the first React island (an interactive piece) is already up and running with the articles table.
Before touching anything visual, I've documented the panel's design system: dark shell, light area, Inter typography and indigo for the data. Each new screen has its criteria written down; they don't have to be invented as they arrive.
How I'll document it
Inside the repository there's a dev-journal (the project's diary) with milestones, decisions, mistakes and solutions. From now on, these notes will explain the process from the outside: what was decided, why, what failed and how it was resolved. They're also part of the investigation: if the base works, why it worked will be written down here; if it doesn't, that too. And to publish it, the path is the one in How this website is published.
The project's rule: don't add unnecessary complexity. Everything that comes in comes in for a reason.