SearchJobs architecture overview

SearchJobs is a full-stack web application composed of a React single-page application, a Spring Boot REST and WebSocket backend, a MySQL relational database, and a MongoDB document store for chat messages. All persistent services run inside Docker containers orchestrated by a single Docker Compose file. The React frontend is developed separately with Vite and communicates with the backend exclusively over HTTP and WebSocket.

Frontend

React 19 SPA built with Vite 7. Handles routing, authentication state, and real-time chat via STOMP over SockJS.

Backend

Spring Boot 3.5 application running on Java 21. Exposes a REST API, Spring Security with JWT, and a WebSocket message broker.

MySQL 8.0

Relational store for users, companies, candidates, vacancies, applications, studies, and work history.

MongoDB

Document store for real-time chat messages between candidates and companies. Connected via Spring Data MongoDB.

Frontend

The React client lives in the client/ directory. It is a single-page application that uses React Router v7 for client-side routing and Tailwind CSS for styling. Key dependencies (from client/package.json):

Package	Version	Purpose
`react`	^19.1.0	UI framework
`react-router-dom`	^7.8.0	Client-side routing
`@stomp/stompjs`	^7.2.0	STOMP protocol client for WebSocket chat
`sockjs-client`	^1.5.2	SockJS transport layer for WebSocket fallback
`sweetalert2`	^11.22.5	Modal dialogs and alerts
`tailwindcss`	^3.4.18	Utility-first CSS framework
`vite`	^7.0.4	Dev server and build tool

Routing and roles

App.jsx defines all routes and wraps them in RouteProtection components that enforce role-based access. The platform supports five roles:

ROLE_INVITADO — unauthenticated visitors; can browse vacancies and register
CANDIDATO — authenticated job seekers; can apply, track applications, and chat
EMPRESA — authenticated companies; can post vacancies and review applicants
ADMIN and SUPER_ADMIN — platform administrators

Public routes (no authentication required) include /, /empleos, /empleos/:id, /login, /registro, and individual company and candidate public profiles.

Authentication flow

The frontend submits login credentials to POST /api/usuarios/login as application/x-www-form-urlencoded. On success the backend returns a JSON object containing the user’s primary role (rolPrincipal). The role is stored in a React context (RoleContext) and used for client-side route guards and conditional UI rendering.

WebSocket / real-time chat

Chat uses STOMP over SockJS. The client connects to the /chats endpoint on the backend. Outbound messages are sent to the /app/chat.sendMessage destination. Inbound messages arrive on per-user queues managed by the simple in-memory broker. The backend allows WebSocket connections from URL_FRONTEND and http://localhost:5173 (configured in WebSocketConfig.java).

Backend

The Spring Boot application is built from ./Proyecto_backup/ and runs on Java 21. Key dependencies (from pom.xml):

Dependency	Version	Purpose
`spring-boot-starter-parent`	3.5.6	Base BOM and plugin management
`spring-boot-starter-web`	—	REST controllers, embedded Tomcat
`spring-boot-starter-security`	—	Authentication, authorization, CSRF config
`spring-boot-starter-data-jpa`	—	JPA repositories, Hibernate ORM
`com.auth0:java-jwt`	4.5.0	JWT generation and validation
`spring-boot-starter-data-mongodb`	—	Spring Data repositories for MongoDB
`spring-boot-starter-websocket`	—	STOMP WebSocket message broker
`com.mysql:mysql-connector-j`	—	MySQL JDBC driver
`nz.ac.waikato.cms.weka:weka-stable`	3.8.6	ML-based candidate-vacancy matching
`org.apache.pdfbox:pdfbox`	3.0.5	PDF CV parsing and text extraction
`springdoc-openapi-starter-webmvc-ui`	2.8.9	Auto-generated Swagger UI and OpenAPI spec
`io.github.wimdeblauwe:error-handling-spring-boot-starter`	4.5.0	Structured error responses

Security

SecurityConfig.java configures Spring Security with:

BCrypt password hashing via BCryptPasswordEncoder
Form login at /api/usuarios/login with a custom success handler that issues a JWT on successful authentication
JWT validation filter (JwtTokenValidator) inserted before BasicAuthenticationFilter to authenticate subsequent requests
CORS configured to allow requests from URL_FRONTEND (set via the app.url.frontEnd property)
CSRF disabled (JWT-based stateless API)

Publicly accessible paths include vacancy listing endpoints, company public profiles, Swagger UI (/swagger-ui/**, /v3/api-docs/**), and the registration endpoints for candidates and companies.

Machine learning

Vacancy-candidate matching is powered by Weka 3.8.6. The backend scores how well a candidate’s profile (skills, education, work history extracted from PDF CVs via PDFBox 3.0.5) matches a vacancy’s requirements and returns a ranked list of applicants to companies.

API documentation

SpringDoc OpenAPI 2.8.9 generates an OpenAPI 3 specification at runtime. The interactive Swagger UI is available at:

http://localhost:8080/swagger-ui/index.html

Database architecture

SearchJobs uses a dual-database strategy: MySQL for all relational data and MongoDB for chat messages.

MySQL — relational data

Stores users, candidate profiles, company profiles, vacancies, job applications, education records, work history, notifications, and appeals. Schema is managed by Hibernate (SPRING_JPA_HIBERNATE_DDL_AUTO).

MongoDB — chat messages

Stores chat message documents between candidates and companies. Chosen for its flexible document model and natural fit for append-only message streams.

MongoDB is not included in the Docker Compose file. You must supply an external MongoDB instance (e.g. MongoDB Atlas or a local mongod) and set MONGODB_URI in your .env file.

File storage

Uploaded files are stored on the local filesystem inside the backend container and persisted through a bind mount:

volumes:
  - ./Proyecto_backup/uploads:/app/uploads

Three upload directories are configured via environment variables:

Variable	Default path	Content
`UPLOAD_DIR_IMG`	`/app/uploads/img/`	Profile photos
`UPLOAD_DIR_PDF`	`/app/uploads/pdf/`	Candidate PDF CVs
`UPLOAD_DIR_VIDEO`	`/app/uploads/video/`	Vacancy introduction videos

The bind-mount approach stores files on the Docker host. For production deployments, replace this with an object storage service (e.g. S3-compatible) and update the upload service accordingly.

Docker Compose services

The docker-compose.yml defines two active services:

services:
  mysql:
    image: mysql:8.0
    ports:
      - "3306:3306"
    volumes:
      - mysql_data:/var/lib/mysql

  backend:
    build:
      context: ./Proyecto_backup
      dockerfile: Dockerfile
    ports:
      - "8080:8080"
    env_file:
      - .env

Both services share the app-network bridge network so the backend can reach MySQL at the hostname mysql. MySQL data is persisted in a named volume (mysql_data).

An Astro-based frontend service is present in the Compose file but commented out. The current active frontend is the React/Vite application in client/, which is run outside Docker during development.

Request flow diagram

Browser
  │
  ├─ HTTP/REST ──────────────────► Spring Boot :8080
  │                                     │
  │                               Spring Security
  │                               (JWT validation)
  │                                     │
  │                         ┌───────────┴───────────┐
  │                         │                       │
  │                    JPA/Hibernate           Spring Data
  │                         │                  MongoDB
  │                      MySQL :3306        MongoDB (external)
  │
  └─ WebSocket (STOMP/SockJS) ──► /chats endpoint :8080
                                       │
                                  Simple broker
                                  /queue, /topic

Environment variables reference

All backend configuration is supplied through the .env file loaded by Docker Compose:

Variable	Description
`SPRING_DATASOURCE_URL`	JDBC URL for MySQL (use `mysql` as hostname inside Docker)
`SPRING_DATASOURCE_USERNAME`	MySQL username
`SPRING_JPA_HIBERNATE_DDL_AUTO`	Hibernate schema mode (`update`, `validate`, etc.)
`MY_SECRET_KEY`	Secret used to sign and verify JWTs (auth0 java-jwt)
`JWT_EXPIRATION`	Token lifetime in milliseconds
`MONGODB_URI`	MongoDB connection string
`UPLOAD_DIR_IMG`	Absolute path inside the container for image uploads
`UPLOAD_DIR_PDF`	Absolute path inside the container for PDF uploads
`UPLOAD_DIR_VIDEO`	Absolute path inside the container for video uploads
`URL_FRONTEND`	Frontend origin used for CORS headers and WebSocket allowed origins

Get Started

User Guides

Deployment

SearchJobs architecture overview

Frontend

Backend

MySQL 8.0

MongoDB

Frontend

Routing and roles

Authentication flow

WebSocket / real-time chat

Backend

Security

Machine learning

API documentation

Database architecture

MySQL — relational data

MongoDB — chat messages

File storage

Docker Compose services

Request flow diagram

Environment variables reference

Build docs developers (and LLMs) love

Get Started

User Guides

Deployment

Documentation Index

Frontend

Backend

MySQL 8.0

MongoDB

​Frontend

​Routing and roles

​Authentication flow

​WebSocket / real-time chat

​Backend

​Security

​Machine learning

​API documentation

​Database architecture

MySQL — relational data

MongoDB — chat messages

​File storage

​Docker Compose services

​Request flow diagram

​Environment variables reference

Build docs developers (and LLMs) love

Frontend

Routing and roles

Authentication flow

WebSocket / real-time chat

Backend

Security

Machine learning

API documentation

Database architecture

File storage

Docker Compose services

Request flow diagram

Environment variables reference