Inside `jobportal`: How One Spring Boot App Splits into Two Products

One Login, Two Dashboards

Most job portal demos start with the obvious part: post a job, search a job, apply to a job. This repo starts somewhere better. It treats identity as the product, then lets the dashboard branch from there.

That choice matters because the app does not need duplicate login screens or separate entry points for each persona. A job seeker and a recruiter share the same authentication spine, then land in different experiences after login. The result is simple on the surface and surprisingly disciplined underneath.

The Data Model Is the Real Product

The most elegant part of the repo is the schema. Instead of inventing separate user systems, it uses one `Users` entity as the base identity, then extends that identity with role-specific profile tables. That is a better fit for the problem than a loose pile of role flags.

The key move is `@MapsId`. It ties the profile primary key to the same identifier as the parent user row, so the profile is not a floating side record. It is a true one-to-one extension of the account. In practice, that makes the data model cleaner to reason about and harder to drift out of sync.

How Spring Security Triage Works

The security setup is doing quiet, useful work. Public routes bypass authentication, then a custom authentication success handler inspects the logged-in user and sends them to a shared `/dashboard/` endpoint. That route is not a dead end. It is a fork in the road.

This is a nice compromise between simplicity and flexibility. The app avoids scattering role logic across multiple login pages, but it still gives each persona a focused surface after authentication. The page may look unified, yet the experience is conditional by design.

That is the real trick here: role awareness happens after login, not before it. The result is a system that is easier to teach, easier to navigate, and less brittle than a hand-built maze of separate auth flows.

Search Is a Filter Bundle, Not a Simple Query

The search controller is a good example of the repo's overall style. It does not pretend job search is one text box and a database lookup. It accepts a high-density bundle of request parameters, then hands that bundle to the service layer for real filtering.

That means the controller is acting like a translator. Form inputs become a search contract. If nothing is set, the app returns everything. If filters are present, the service takes over. The shape is closer to a specification engine than a naïve query endpoint.

Applications Are State, Not Just Submissions

The apply flow makes the same point from a different angle. Applying is not just inserting a row. The controller checks prior state, such as whether the user already applied or already saved the job, then creates a new application record with user context and a timestamp.

That matters because it turns the app into a history machine. A candidate is not just a guest clicking buttons. They accumulate state over time. Saved jobs, applications, profile data, and activity records all shape what the dashboard can show next.

This is where the design becomes coherent. Search discovers jobs. Saving marks intent. Applying records commitment. The system is not random CRUD. It is a small workflow engine wrapped in a familiar portal.

A lot of portfolio projects stop at form submission. This one goes one step further and asks, what should the system remember about the user after the click? That is a much more interesting question.

The File System Tradeoff

Uploads live in a local `photos/` directory, including resumes and profile images. That is a practical choice for a portfolio project because it keeps setup easy and avoids cloud dependencies.

The cost is obvious too. Local files are simple on one machine and awkward across multiple instances. They are fine for learning and demos. They are not the final word on durability or scale.

That tradeoff does not weaken the project. It clarifies it. You can see exactly where the code stops being a teaching tool and starts becoming production infrastructure.

Why This Feels Like a Strong Portfolio Project

This repo succeeds because it is more than a list of features. It demonstrates layered Spring architecture, role-aware security, JPA relationships, and a dashboard model that reflects how real software separates shared identity from role-specific behavior.

Compared with the average job portal demo, it has a sharper idea. Many projects duplicate paths for each persona or bury role logic in the UI. This one keeps a single spine and lets the system branch where it should.

That is why the repo stands out. It is educational, but not toy-like. It gives you a clean example of how to structure a Spring Boot app around identity, state, and role-based experiences without overcomplicating the surface area.