// the find
wq/django-rest-pandas
📊📈 Serves up Pandas dataframes via the Django REST Framework for use in client-side (i.e. d3.js) visualizations and offline analysis (e.g. Excel)
Django REST Pandas bridges Django REST Framework and pandas, letting you expose Django querysets as DataFrames served in CSV, Excel, JSON, PNG, or SVG formats via a standard REST API. It's aimed at teams building data-heavy Django apps who want to feed client-side charts or let users export data to Excel without writing custom export logic. The wq ecosystem wraps it with Plotly-backed chart components, though you can use the data API standalone.
The renderer architecture is genuinely well-designed — adding a new output format is a single class implementing `render()`, and the existing set (CSV, XLSX, PNG, SVG, JSON) covers most real export requirements out of the box. The serializer layer that pivots DRF output into a DataFrame before rendering means you get pandas' full reshaping power (unstacking, box plot aggregation, scatter prep) declared at the serializer level rather than scattered through view logic. It's been maintained continuously since 2014 and the test suite covers format output, multi-series, and Excel edge cases with actual file comparisons. Django/Python version support is kept current.
The tight coupling to the wq ecosystem is a recurring friction point — documentation leans heavily on @wq/chart and @wq/analyst, so if you just want a standalone data API the signal-to-noise ratio in the docs is poor. Streaming large DataFrames isn't addressed; a queryset that materialises a million rows into memory before rendering will OOM quietly. The image renderers (PNG/SVG) require matplotlib installed separately and produce static charts server-side, which is an odd choice in 2026 when the stated use case is feeding client-side d3/Plotly. Async Django (ASGI) support isn't mentioned anywhere and the view layer is all synchronous, which matters if you're on a modern Django stack.