Skip to content
Back to projects
In productionjacintalynch.art

CuadrosJaci

Web catalogue for an artist, on its own domain.

  • Python 3.12
  • Django 5
  • Django REST Framework
  • PostgreSQL 16
  • React
  • Vite
  • Docker
  • pytest
View live
A walkthrough of jacintalynch.art: the catalogue grid and the detail view for the piece Doberrman, with its description and availability.

The problem it solves

An artist showing work on social media depends on the algorithm and has no way to present an organised catalogue: by style, by medium, by size. Someone asking about a specific piece ends up scrolling through old posts.

What it does

A filterable catalogue on its own domain. The backend is a deliberately simple read-only API; the weight is on the frontend and on the site being reliably available.

Architecture

A second application on the same server as Caudal, sharing the reverse proxy but with its own isolated database. The frontend isn't served by Node: it's built to static files the proxy delivers directly.

  1. Edge

    Caddy

    The same one serving Caudal, on a different domain with its own certificate.

  2. Application

    React + Vite (build estático)

    Pre-built files. There's no Node process running in production.

    Django REST Framework

    Read-only API, no authentication. UUIDs as primary keys.

  3. Data

    PostgreSQL 16

  • Container and volume names follow a mandatory convention: the server's backup discovers what to do from them, and an app that ignores it silently goes unbacked-up.
  • Deployed from a git clone with a read-only deploy key, so the server has no write access to the repository.

The hard part

Adding a second application to a server already serving one

The real challenge here wasn't the backend, which is simple on purpose. It was taking the server from one application to two without the second being able to break the first: per-container memory and CPU limits so a misbehaving app can't starve the other, log rotation so logs don't silently fill the disk, and a naming convention that makes a new app get picked up by backups automatically. An app that ignores the convention goes unbacked-up without anyone noticing — the worst kind of failure.

Technical decisions

  • Static frontend build served by the proxyinstead ofserving it with Vite's dev server

    Because A dev server isn't built for production: no compression, no caching, and the attack surface of a development tool. The proxy serves static files and does what it's good at.

  • UUIDs as primary keysinstead ofauto-incrementing integers

    Because Sequential IDs on a public API leak how many pieces exist and let anyone enumerate them. Not critical for a catalogue, but the cost of avoiding it was zero.

What I learned

That the second application on a server is what reveals whether the infrastructure work was done properly. With one app many decisions look optional; with two, every missing one shows.

What's next

Serving uploaded images straight from the proxy, and expanding catalogue filters.

In short

  • Client site, in production
  • Read-only REST API, no authentication
  • Deployed from a git clone with a read-only deploy key