Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/JuanSebax85/backend-prueba-fullstack/llms.txt

Use this file to discover all available pages before exploring further.

Backend Prueba Fullstack is a REST API for academic management. This page introduces the three core resources, how they relate to each other, the technology stack, and the key architectural decisions that shape how you interact with the API.

Core resources

The API exposes three resources:
  • Alumno — a student record with personal details (name, surname, email, date of birth).
  • Materia — an academic subject with a name, code, and credit value.
  • Nota — a grade that links one Alumno to one Materia, recording the numeric value and the date it was registered.

Relationships

Alumno ──< Nota >── Materia
A single Alumno can have many Notas. A single Materia can have many Notas. Each Nota belongs to exactly one Alumno and one Materia. The foreign keys alumno_id and materia_id on the Nota table enforce this at the database level.

Data model

FieldEntityTypeNotes
idAlumno, Materia, NotaLongAuto-generated primary key
nombre, apellidoAlumnoStringFirst and last name
emailAlumnoStringContact email
fechaNacimientoAlumnoDateDate of birth
nombreMateriaStringSubject name
codigoMateriaStringSubject code
creditosMateriaIntegerCredit value
valorNotaDoubleNumeric grade
fechaRegistroNotaDateDate grade was recorded
alumno_idNotaFK → AlumnoForeign key
materia_idNotaFK → MateriaForeign key

Technology stack

ComponentTechnology
LanguageJava 17
FrameworkSpring Boot 3
PersistenceSpring Data JPA
DatabasePostgreSQL 15
Build toolMaven
ContainerizationDocker & Docker Compose
Boilerplate reductionLombok

Architecture

The API follows a straightforward three-layer path from HTTP request to database:
HTTP request


REST controllers   (handle routing, validation, business rules)


JPA repositories   (Spring Data interfaces for CRUD)


PostgreSQL 15      (relational storage)
There is no dedicated service layer. Business logic lives directly in the controllers. This keeps the codebase compact but means the controllers are responsible for enforcing rules that would typically belong in a service class.

Key design choices

No service layer

Controllers call repositories directly. If you are reading the source code or extending the API, expect to find query logic and validation inside the controller methods rather than in a separate @Service class.

Referential integrity enforced at the controller level

The database schema allows cascade deletes to be avoided by checking for dependent records in the controller before executing a delete. Attempting to delete an Alumno that has associated Notas returns 400 Bad Request instead of removing the record.
You must delete all Notas belonging to an Alumno before you can delete that Alumno. The same applies to Materias that are referenced by existing Notas.

DTO pattern for Nota responses

When the API returns a Nota, it uses a Data Transfer Object (DTO) rather than the raw entity. This controls the shape of the JSON response and avoids serialization issues that arise from bidirectional JPA relationships.

Schema management

The application uses spring.jpa.hibernate.ddl-auto=update, so Hibernate automatically creates or updates tables on startup to match the entity definitions. You do not need to run migrations manually during development.

CORS

The API allows cross-origin requests from http://localhost:3000. If you are building a frontend that runs on a different origin, you will need to update the CORS configuration in the source code.

What’s next

Quickstart

Clone the repo, start the services with Docker Compose, and make your first API call in minutes.

API reference — Alumnos

Full endpoint reference for creating, reading, updating, and deleting student records.

API reference — Materias

Full endpoint reference for managing academic subjects.

API reference — Notas

Full endpoint reference for recording and querying grades.

Build docs developers (and LLMs) love