Case study · Creative platform prototype
A city is
not a list.
The network before the interface
Novera models Rome’s cultural scene as a connected system of people, events, places and districts — before every connection is fully exposed in the interface.
Tonight in San Lorenzo
Start with something concrete: one evening, one district and one screen getting its data from the backend.
-
Telemetry
- Endpoint
- GET /api/home
- Rendering
- React Server Component — fetched server-side
- Data
- One seeded city · 29 domain records
- Recorded in
- Laravel access log
The home is currently the only main frontend screen fed by the aggregated Laravel API. The city header, counters and activity feed all come from one endpoint, fetched and rendered by a React Server Component.
That fetch runs on the server, so it never appears in the browser’s network panel. The request is visible in the Laravel access log.
Counts shown on screen are demo-data totals, not usage metrics.
Everything is somewhere
The district is not a tag. It is a first-class relation carried by every entity in the domain.
Referenced in
San Lorenzo
- Artists 1
- Events 1
- Spaces 1
- Collectives 1
- Live rooms 1
- Open calls 1
Artists, events, spaces, collectives, live rooms and open calls all hold a district reference. That single decision is what allows a scene to be read by place rather than by category.
San Lorenzo is the only district connected to all six categories in the seed. Monti has no references yet, and the field shows that.
Districts carry an editorial tone and abstract layout coordinates in the schema — the field above is drawn from those map_x / map_y values, scaled to fill the frame. There is no latitude, no map tiles and no geolocation anywhere in the product.
Follow the connection
An artist plays an event, the event happens in a space, the space sits in a district, the district holds collectives and open calls.
The join that turns six separate directories into one readable scene.
Novera models that chain with foreign keys on every hop, plus polymorphic references that let activity and recommendation records point to any entity.
The relationships exist in the domain model even where the current interface does not yet make them navigable.
- Artist
- belongsTo City, District — A profile with discipline, tags, links and skills, anchored to a district.
- Event
- belongsTo Space, Collective, District · hasMany OpenCall — An event knows where it happens, who organises it and which calls it opens.
- Space
- belongsTo City, District — A venue with type, capacity and amenities, placed in a district.
- District
- referenced by every domain entity — The join that turns six separate directories into one readable scene.
- Collective & open call
- belongsTo District · OpenCall belongsTo Collective, Event, Space — Where a scene turns from things happening into people looking for each other.
Two halves
The project currently has two uneven halves, shown in one drawing.
Finished
- 19 read-only endpoints
- 10 domain entities
- API Resources with shared basics
- Eloquent relations, incl. polymorphic
- Shared city / district / status filters
- One aggregated home response
Highlight surfaces by data source
API-backed surface highlighted
Laravel exposes nineteen read-only endpoints across ten entities, with API Resources, eager-loaded relations and a shared filter layer. The Next.js app consumes exactly one of them. Everything else — the artists, events and rooms directories — runs on local arrays declared in the components themselves. They are complete interfaces over demonstration data.
The TypeScript types describing the API are written by hand, so the contract between the two halves is a convention rather than something generated or checked at runtime.
Filtering a scene
The events directory is the clearest example of the split: demonstration data underneath, genuine interaction on top.
The directory runs on local demonstration data, but its filtering logic is real: two active filters reduce twelve records to four. Filtering combines several axes at once — type, period, access, capacity, neighbourhood and a text query — and each control is a real toggle with its pressed state exposed to assistive technology.
This 12-to-4 result comes from the running application.
Modelled, not yet lived
This is where the prototype stops today.
- Ten domain entities
- Nineteen read-only endpoints
- District as a first-class relation
- Polymorphic activity and recommendation records
- One aggregated home response
- Client-side event filtering
- Authentication
- Content creation
- Applications to open calls
- Persistent follow, save and join actions
- Full directory-to-API integration
- Real multi-city data
- Calculated recommendations
- Production deployment
The interface offers a city selector, but the backend holds one seeded city and the home controller resolves Rome explicitly. It does not demonstrate multi-city support.
Recommendation records are modelled but not calculated. Their scores and reasons are demonstration content, not algorithmic output.
All photography in these screens is stock reference material, not application content.
What is finished here is a way of describing a city.
What is not finished is everything that would let people live inside it.