5 min read

Choosing a Stack: Astro, FastAPI, PostgreSQL

architecture astro fastapi steforge
Русская версия

Choosing technologies is one of the first decisions that defines everything that follows. For Steforge, the stack was chosen based on several criteria: simplicity, performance, maturity, and suitability for solo development.

Public Layer: Astro

The blog and product showcase are static content. Here, React is not needed, Next.js is not needed, and server-side rendering on every request is unnecessary.

Astro fits perfectly:

  • Content Collections — typed content with validation
  • MDX — interactive components right in the articles
  • Static Generation — fast loading, minimal hosting
  • Island Architecture — JavaScript only where needed

Two domains (steforge.ru and steforge.com) are built from a single project with language filtering.

System Layer: FastAPI + PostgreSQL

User dashboard, billing, application catalog — this is already backend. Here, the choice fell on Python:

  • FastAPI — fast, typed, asynchronous
  • SQLAlchemy Async — ORM with async/await support
  • Alembic — database migrations
  • PostgreSQL — reliable DBMS, storage in Russia

Why Not Monolith

Each MVP in the ecosystem is a separate service. This is a conscious decision:

  • One failed MVP does not bring down the others
  • Each service can be updated independently
  • Easier to control expenses for each product

The Gateway routes traffic, while auth and billing are centralized.

Proxy Layer

All outgoing calls to external APIs go through api-broker. This allows:

  • Filtering payload before sending
  • Masking personal data
  • Logging call metadata
  • Managing providers centrally

For more details about the proxy, visit the product page API Proxy.