Explore: rebuild frontend as a Vite SPA on top of a read-only JSON API

[bjageman]

Summary

Explore replacing the current server-rendered UI (Django templates + Bootstrap4 + jQuery, via django-bootstrap4/django-tables2/django-filters) with a modern SPA frontend (e.g. Vite + React/Vue), while keeping the existing Django app and Postgres database as the source of truth.

Motivation

The core data users actually care about is already clean and well-modeled:

• ScriptVersion.content — the full script definition as a JSONField
• ScriptVersion.pdf — the associated rendered PDF (FileField)
• Supporting metadata already on the model: name, author, tags, edition, homebrewiness, and per-role-type character counts (townsfolk/outsiders/minions/demons/fabled/travellers/loric)

None of that requires touching the underlying data model. What's missing is a clean way to get it out as JSON — today it's only exposed via server-rendered HTML views (AdvancedSearchView, SingleTableView from django-tables2, etc.), which mix query-building, form handling, and HTML rendering in the same view classes.

Proposed approach

1. Add a read-only JSON API (e.g. via Django REST Framework) exposing ScriptVersion + content + a PDF URL + search/filter query params, reusing the existing queryset-building logic currently embedded in AdvancedSearchView.form_valid (scripts/views.py).
2. Build a new frontend (Vite + React/Vue) against that API for browsing/searching/viewing scripts and PDFs.
3. Leave write paths (upload, voting, comments, favourites, auth) on the existing Django views/templates initially; migrate incrementally if/when it's worth it.

Trade-offs / open questions

• This scopes the rewrite to browse/search/view only — anything that writes still depends on the legacy views until a decision is made to port those too.
• Need to decide on auth strategy for the API (session auth reused from Django, or token-based) if authenticated features (favourites, votes) are ever added to the new frontend.
• Building the API layer is real work, comparable in size to the frontend rewrite itself — not just a thin pass-through.

Related

Filed after digging into the search 500 error (missing pg_trgm Postgres extension) and reviewing the current template/view structure while discussing this idea.