UCO Data Portal stack

A portal for delivering environmental and climate data publicly. It is the project in this garden that does not use FastAPI, and that is the reason it is worth documenting.

The stack

• Frontend: Nuxt 3 over Vue 3, with Vuetify and OpenLayers for mapping.
• Backend: Django REST Framework, with OpenAPI schema generation through drf-spectacular.
• API style: conventional REST endpoints.

What the contrast shows

Set against the FastAPI projects, the pattern that survives is not the framework. It is the schema-first contract: drf-spectacular generates OpenAPI from Django serializers much as FastAPI generates it from Pydantic models, and the frontend consumes the result the same way either side. The typed-contract discipline is portable; the framework is an implementation detail of how the schema gets produced.

That is genuinely useful to know, because framework choice usually gets argued as though it determined the architecture. Here it did not.

Where Django earned its place

Two things pushed the decision. Django’s admin interface is substantial and free, and for a data portal with curators who are not developers, an admin that exists on day one is worth a great deal. The ORM and migration story is also more mature than the SQLModel and Alembic combination, which matters when the data model is complex and long-lived rather than iterating quickly.

The cost is that Django REST Framework is more ceremonious than FastAPI. More files, more indirection, and async support that arrived later and fits less naturally. For a service that is mostly I/O-bound endpoints, FastAPI does less work per feature.

Serving a public data product

Two things mattered here that do not in an internal application. Publishing the API schema explicitly means third parties can build against the portal without asking anyone, which is the same argument FAIR makes about data — machine-readable interfaces remove the human negotiation step. And Nuxt was chosen over plain Vue mainly for server-side rendering, because a public data portal needs to be findable, and a client-rendered SPA is not.

OpenLayers for the mapping, since the interfaces are map-heavy and it handles projected coordinate systems properly — which matters more than it sounds given how easily a reference system mismatch produces plausible, wrong maps.

See also: APIs, REST, the UC2 data standard for the data conventions behind portals like this, and the web architecture map.