UNP Campus Map is an independent open-source project, not an official Universidad Nacional de Piura product. Its maintained surface is a searchable faculty and school directory with administrative content management. Interactive geospatial navigation remains future product work rather than a shipped capability.
PROJECT CASE STUDY · ACADEMIC DIRECTORY
UNP Campus Map
An independent open-source academic directory for National University of Piura faculties and schools, built on Next.js 16 App Router with database-backed search, administrative CRUD and Cloudinary media.
Public source Maintained
CURRENT PRODUCT
A searchable academic directory, with geospatial mapping still on the roadmap
PROBLEM
Campus information is more useful when it is structured and searchable
Faculty names, schools, pavilion references and official links are easier to use when they live in one queryable directory instead of being rediscovered across unrelated pages or documents. The current implementation therefore centers on faculty and school discovery before adding map-specific interaction.
SYSTEM
Next.js owns both the public directory and its administrative surface
Current UNP Campus Map architecture Public and administrative App Router surfaces reach API and service code. A faculty service queries through Knex, which can target the default MySQL configuration or PostgreSQL. Cloudinary stores managed media.
IMPLEMENTATION
What the code supports today
DISCOVERY
FACULTIES + SCHOOLS
The service layer selects faculties, counts related schools and searches across faculty names, descriptions and school names. School records expose pavilion and official website information.
CONTENT
ADMINISTRATIVE CRUD
The current App Router tree includes an admin area, while facultyService implements
create, update and delete operations against the same persistence boundary used by
public reads.
MEDIA + DATA
CLOUDINARY + KNEX
Media configuration is separated through Cloudinary. Database access is centralized behind Knex and the repository carries both MySQL and PostgreSQL schema paths rather than binding every query to one driver.
CURRENT STACK
Next.js 16, React 19 and Tailwind 4
IMPLEMENTATION
NEXT.JS 16 · REACT 19 · TAILWIND 4
The current application uses Next.js 16.0.10, React 19.2.3 and Tailwind CSS 4.1.17, with App Router route handlers, service-layer queries and administrative CRUD around the academic directory.
PRODUCT ROADMAP
INTERACTIVE MAPPING REMAINS FUTURE WORK
Interactive mapping and geospatial navigation remain future product work. The current product stops at a searchable, administrable directory until that navigation layer is implemented.
TRADE-OFFS
A directory first, map later
Building the data model, search and content-management path first creates a reliable information layer that a future map can consume. It also avoids coupling the value of the project to GPS or geospatial UX before the underlying faculty and school records are dependable.
Knex adds a small abstraction layer, but it gives the application one query surface for the default MySQL configuration and the supported PostgreSQL path.
LEARNINGS
What the project reinforced
LEARNING 01
SHIP THE RELIABLE INFORMATION LAYER FIRST
The directory delivers useful discovery before the geospatial layer is ready, and gives future map interaction a structured data source to build on.
LEARNING 02
KEEP CONFIGURATION AND DOCUMENTATION ALIGNED
Dependency and architecture changes are easier to maintain when executable configuration, routes and documentation evolve together.
LEARNING 03
PORTABILITY NEEDS A REAL BOUNDARY
Supporting more than one database is meaningful when queries flow through one adapter layer and both schema paths exist, not when portability is only a documentation claim.