Full-stack academic project · 2024–2025

Cont-Air-Near.

A cargo shipping and port-operations management system connecting a React interface, FastAPI REST API and relational data model in one role-aware application.

View repository My contributions

My role: Programmer & project lead
Team: 4 developers
Contribution: 80 commits*
Status: Completed

Application gallery

Four roles, fifty views

The running application, captured from a local instance with its three seeded demonstration accounts: what a guest, an administrator, an employee and a client are each offered, the REST API underneath and the phone layout. Pick a set from the rail - each has its own strip, counter and full-size view. Every name, email address and phone number on screen is generated seed data.

Sign-in and registration

What a guest is offered: the landing page, the JWT login, self-service registration and the validation on both forms.

The Cont-Air-Near landing page with a Welcome heading and only a Login link in the navigation bar. — Landing page for guests
The public landing page of Cont-Air-Near. A guest is offered a single Login link in the navigation bar; every management module stays hidden until the user authenticates.

The login form with Login Name and Password fields, a Show Password option and a link to registration. — JWT-based login
The login form exchanges credentials for a JWT access token issued by the FastAPI backend. Passwords are verified against bcrypt hashes, and the token drives every later role check in the React client.

The login form with both fields outlined in red and a required-field message under each. — Login validation
Submitting the empty form triggers inline, field-level validation before any request reaches the API: Login is required, Password is required. Clear messages guide the user and keep invalid traffic away from the backend.

The registration form with login name, password, email, name, address and telephone number fields. — Self-service registration
New users create an account with a login name, password, email, name, address and telephone number. Accounts created through this form get the CLIENT role, and passwords are stored only as bcrypt hashes.

The registration form with every field in an error state and its rule spelled out underneath. — Registration validation
Every field carries an explicit rule: an alphanumeric login of at least 4 characters, a password of at least 8, a well-formed email address and a phone number of 7 to 15 digits. The backend validates again and adds a disposable-email-domain blocklist.

01 / 05

REST API

The FastAPI backend through its own Swagger UI: the endpoint catalogue, a typed contract, a live 401 and the Pydantic schemas.

Swagger UI listing the ship and operation endpoints by HTTP method, some marked with a padlock. — Swagger UI overview
FastAPI generates OpenAPI 3.1 documentation for the whole REST API and serves it at /docs. Each resource exposes create, read, update and delete endpoints, and a padlock marks the operations that require a bearer token.

An expanded Swagger endpoint showing the id_ship parameter and an example JSON response with nested operations. — Typed endpoint contract
The ship details endpoint expanded: its path parameter, its response codes and a Pydantic-generated response schema. The contract nests the ship's related operations, mirroring the SQLAlchemy relationships in the data model.

Swagger UI showing a GET request for a port answered with 401 Unauthorized and a Not authenticated body. — 401 without a token
A live request to a protected endpoint without a token is rejected with 401 Not authenticated and a WWW-Authenticate: Bearer header. Access control is enforced on the server, not only hidden in the interface.

The Swagger schema list with Create, Read, Update and Details models for orders, order products and ports. — Pydantic schemas
The schema catalogue lists separate Create, Read, Update and Details models for orders, ports, operations and the other entities. One model per use case keeps request validation strict and responses predictable.

01 / 04

Administrator

Every module, through the one role that sees them all: products, ships, operations, ports, orders and client accounts, with their detail pages and dialogs.

The Products page showing a grid of product cards with images, prices, weights and ports under a search toolbar. — Product catalogue
Cargo products as responsive cards with price, weight, origin port and an uploaded image. Staff roles get the Add Product action, while search, field filter, sorting and pagination sit above the grid.

The Products page filtered by the term Chair on the Name field and sorted by Price, showing five matching cards. — Search, filter and sort
The shared search bar filters the catalogue live: here the term Chair is matched against the Name field and the results are sorted by Price. The same reusable component powers every list view in the application.

The Add New Product dialog with name, price, weight, image file and port fields over the product grid. — Add product with image upload
The Add New Product dialog takes a name, price, weight, an image file and the port where the product is stored. Images are uploaded to the FastAPI backend and served back through a dedicated image endpoint.

A product detail page with price, weight and port beside the product image, and Update and Delete buttons below. — Product details
Each product has a detail page with its attributes, the full-size image, a link to its port and any associated orders. Update and Delete appear only for the employee and administrator roles.

The Update Product dialog pre-filled with the product's name, price and weight, with a Delete Image checkbox. — Edit product
The update dialog arrives pre-filled with the current values, so staff change only what is needed. The stored image can be replaced with a new upload or removed with the Delete Image option.

The Ships page showing a grid of ship cards, each with a name, an active or inactive status and an image. — Fleet overview
The Ships module lists the fleet as image cards with an active or inactive status, under the same search, sort and pagination toolbar as the rest of the application.

A ship detail page with the ship's status and image above a table of its three operations. — Ship details and operations
A ship's page combines its status and image with a table of every operation it took part in - arrivals, departures, transports. Each row links to the operation, which makes the ship-to-operation relationship easy to follow.

The Update Ship dialog with the ship name, an image file picker and a Delete Image checkbox. — Update ship
Staff can rename a ship and replace or delete its image from one focused dialog. The form is pre-populated from the API, and changes are saved through an authenticated PUT request.

A Confirm Deletion dialog asking whether to delete this ship, with Cancel and Yes, delete buttons. — Confirm before delete
Deleting a record always asks for explicit confirmation and warns that the action cannot be undone. The same guard covers ships, ports, products, orders, operations and clients.

The Add New Ship dialog with a ship name field and an image file picker over the fleet grid. — Register a ship
A minimal dialog for adding a vessel to the fleet: a name and an optional image. A small form means fewer input errors and faster data entry.

The Operations page listing operations by name with their type, date, ship and port. — Port operations log
The Operations module records cargo loading, cargo discharge, arrivals and transfers. Each row ties an operation to its type, date, ship and port, in a compact list layout suited to dense operational data.

An operation detail page with its name, type and date beside links to its ship, port and order. — Operation details
An operation connects three other entities: the ship that performed it, the port where it happened and the order it serves. All three are links, so the data model can be crossed in a single click.

The Add New Operation dialog with name, type, date, ship, port and order fields. — Schedule an operation
The Add New Operation form offers a typed operation category, a date-time picker and dropdowns filled with existing ships, ports and orders. Choosing from live data prevents orphaned or inconsistent relationships.

The Ports page listing ports by name with their location and country, and an Add Port button. — Port directory
Every port with its city and country, searchable, sortable and paginated. Employees and administrators can add ports, while clients see the same directory read-only.

A port detail page with the port's name, location and country above tables of its operations, orders and products. — Port details
The port page gathers everything tied to one location: the operations carried out there, the orders to be delivered to it and the products stored in it - the one-to-many relationships modelled with SQLAlchemy.

The Orders page listing every order with its status, description, port and client, and an Add Order button. — All orders
Administrators see every order in the system with its status, description, destination port and client. Only this role is offered Add Order, for creating orders on behalf of clients.

An order detail page with status, port and client above tables of its operations and products. — Order details
An order's page shows its status, destination port and client beside the operations that fulfil it and the products it contains. Staff roles can update or delete the order from here.

The Update Order dialog with status, description, port and client pre-filled. — Update order status
Staff move an order through its lifecycle - pending, shipped, delivered, cancelled - and adjust its description, port or client. The dialog is pre-filled with the order's current state.

The order-product list showing order, product and quantity per row, each with Update and Delete buttons. — Order line items
The order-product view exposes the many-to-many relationship between orders and products, quantities included. Administrators can add, update and delete line items, with page-number navigation across the full set.

The Clients page listing accounts with address, telephone number and email, starting with the three default accounts. — Client accounts
The Clients module is offered only to administrators, and the API rejects account deletion for any other role. The list covers every account, including the default admin, client and employee users; every record shown is generated demonstration data.

A client detail page with contact details, logon name and a CLIENT role badge above a table of associated orders. — Client profile and orders
An account's page shows contact details, logon name, assigned role and every associated order. Administrators can update or delete the account from here.

The Update Client dialog with contact fields, a role dropdown set to Client and Keep the old password ticked. — Role assignment
Administrators can edit any account and switch its role between Client, Employee and Admin. A Keep the old password option lets them update profile data without resetting credentials.

The Add Client dialog with name, email, telephone, address, logon name, role and password fields. — Create account with a role
Unlike public registration, this administrator form creates an account and chooses its role up front. Passwords are hashed with bcrypt before they are stored.

The Ships page with the Items per page dropdown open, offering 1, 5, 10, 25 and 50. — Configurable pagination
List views offer first, previous, next and last navigation with a page size of 1, 5, 10, 25 or 50 items. Pagination keeps large datasets responsive in the browser.

01 / 25

Employee

The same application with the Clients module removed and order creation withheld - staff run operations, not accounts.

The Ships page as an employee, with the Add Ship button available. — Employees manage the fleet
Employees have full access to fleet management, Add Ship included. Day-to-day operational data is kept by staff without needing administrator privileges.

The Update Operation dialog over an operation detail page, signed in as an employee. — Employees update operations
An employee edits an existing cargo-loading operation: its name, type, date, ship or port. Create, update and delete rights on operations are shared by the employee and administrator roles.

The Orders page as an employee: the same list of orders, with no Add Order button. — Orders without Add Order
Employees see all orders across the organisation and update them from the detail page. The Add Order button shown to administrators is deliberately missing for this role.

The order-product list as an employee, with no Add, Update or Delete buttons. — Read-only line items
The same order-product list the administrator saw, now without the Add, Update and Delete controls - role-aware action buttons driven by the authenticated user's role.

01 / 05

Client

The customer's side: a reduced menu, the catalogue without management actions, the cart through checkout, and only their own orders.

The Products page as a client: the product grid with Add to Cart buttons and no Add Product button. — Catalogue as a client
Clients browse the same catalogue with search, sorting and pagination, and can add items to their cart. Management actions such as Add Product are not offered.

A product detail page as a client, showing a bed with its price, weight and port and no Update or Delete buttons. — Product details, no management
The client's view of a product shows its specification, image and port. The Update and Delete buttons staff see are not rendered for this role.

The Ports page as a client, listing ports with no Add Port button. — Read-only port directory
Clients can look up the available ports when planning a delivery but cannot add or modify them. Add Port is reserved for employees and administrators.

The cart with three products, total price and weight, and a Port must be selected error on the delivery port field. — Cart with checkout validation
The cart lists the selected cargo with price and weight badges and totals both. Trying to place an order without choosing a delivery port is blocked with an inline validation message.

The cart with a delivery port selected, three products, the totals and a Place Order button. — Cart ready for checkout
With a delivery port selected the order can be placed. Checkout creates the order and its product line items through the REST API in a single flow, then clears the cart.

The Orders page as a client, showing a single pending order belonging to the signed-in account. — Only the client's own orders
After checkout the new order appears at once with a pending status. The Orders view loads only the orders linked to the signed-in client's account, unlike the organisation-wide list staff see.

An order detail page as a client with a pending status, the delivery port and a table of three purchased products. — Tracking an order
The client can open their order to review its status, destination port and purchased products. The view is read-only: update and delete remain reserved for staff roles.

Self-service profile

From the User Panel every role can update its own login name, email, name, address and telephone number. The password can be kept or replaced in the same form.

01 / 09

Mobile layout

The same React interface on a 390-pixel phone viewport: a single column and a collapsible menu that is still role-aware.

The Products page on a phone: stacked search controls above a single-column product card. — Products on a phone
On a phone-sized viewport the Bootstrap-based interface collapses into a single column with full-width search and filter controls. Product cards stay readable and fully functional on a small screen.

The phone layout with the hamburger menu open, listing Ports, Orders, Products, User Panel, the cart and Logout. — Collapsible navigation
The navigation bar folds into a hamburger menu on small screens and still renders role-aware links - here the reduced set of modules the client role is offered.

01 / 02

Overview

One system for connected shipping operations

The project was built from scratch rather than configured from an existing CMS. That made the work more demanding, but gave the team control over the data model, permissions and workflows needed for ships, ports, products, clients and orders.

The result is a full-stack application with a React client, REST API, account system and relational persistence. It demonstrates how interface behavior, domain relationships and security rules must work together-not as separate coursework exercises, but as one usable product.

My work

From authentication to integration

The academic report and Git history show contributions across backend, frontend, security, data modelling and team delivery.

Authentication & security

Built registration and login across FastAPI and React, implemented JWT access tokens and bcrypt password hashing, added validation, session-expiry logout and disposable-email-domain blocking.

Authorization & administration

Introduced GUEST, CLIENT, EMPLOYEE and ADMIN roles; protected backend endpoints, frontend routes and actions; restricted client order access; and built administrative client management.

Full-stack feature work

Created foundational Operation, Port and User functionality, developed CRUD workflows and relationships, built early React interfaces and connected them through a shared Axios API service.

Leadership & integration

Led a four-person project, coordinated delivery, integrated feature branches, resolved conflicts, reviewed merges, repaired CI and handled cross-module bug fixing before final delivery.

*The repository attributes 80 commits to my x0-lf and s19568 identities. Merged feature branches can duplicate commit history, so capabilities-not raw volume-are the main evidence presented here.

Application scope

Full feature overview

The application models a small cargo marketplace and its connected port operations.

01CRUD workflows for ships, ports, products, clients, orders and operations
02Relationships between cargo, vessels, ports, clients and order records
03Search, filtering, sorting, pagination and grid/list interfaces
04Shopping-cart and checkout workflows
05Product and ship image upload and replacement
06Role-aware navigation, protected routes and client-specific data
07Default demo data and interactive Swagger API documentation
08Responsive Bootstrap-based React interfaces

Technical architecture

Three layers, one permission model

JWT travels from the React client through the API, where role checks protect operations before SQLAlchemy accesses SQLite.

React UI

Routes, forms, role context, navigation and shared Axios API service.

FastAPI

REST routes, Pydantic validation, JWT verification and authorization utilities.

SQLAlchemy

Domain models and relationships persisted in a seeded SQLite database.

Frontend

React 18, React Router, Axios, React Bootstrap, React Hook Form

Backend

Python, FastAPI, Pydantic, Uvicorn

Persistence

SQLAlchemy, SQLite

Security

JWT, bcrypt, role-based authorization

Delivery

Git, GitHub Actions, npm, pip

What I learned

Technical decisions and team responsibility

01Designing authentication as an end-to-end flow rather than an isolated backend feature
02Applying authorization consistently across API endpoints, routes and visible interface actions
03Modelling connected business entities with SQLAlchemy and relational databases
04Integrating independently developed modules without losing a coherent user experience
05Balancing delivery, code review, debugging and team coordination as project lead
06Recognising production gaps in secrets, default credentials, tests and deployment hardening

Team context

Built collaboratively

Cont-Air-Near was a four-person academic project. I served as project lead and full-stack programmer. Fabian Zbrański worked on core setup, ships, orders, related records, filtering and cart integration; Maciej Chojecki worked on products, images, pagination, styling and the user panel; Michał Joński-Jastrzębowski worked on clients, cart, order history, QA and relationship fixes.

Shared ownership is part of the project’s value: the challenge was not only writing features, but coordinating independent work into a coherent application.

Repository structure

backend/
  models/       Domain models
  routes/       REST endpoints
  utils/        Authorization and email tools
  main.py       FastAPI application
frontend/src/
  components/   Domain and shared UI
  contexts/     Role context
  pages/        Routed pages
  services/     Axios API client
.github/        CI workflow

Project status

Completed demonstration project

Delivered in January 2025 and cleaned up for portfolio use. The repository includes corrected Python 3.13 setup instructions and seeded local demo accounts for ADMIN, CLIENT and EMPLOYEE roles.

API resources

Ships, ports, products, operations, orders, order products, clients, cart and checkout-documented through FastAPI Swagger UI.

Security note

Demo credentials are for local use only. Production deployment would require new secrets, removed defaults, updated dependencies, broader automated tests and hardened deployment configuration.

Explore the code

Authentication, CRUD and team integration in one repository.

Open GitHub

Cont-Air-Near.

Four roles, fifty views

Sign-in and registration

Landing page for guests

JWT-based login

Login validation

Self-service registration

Registration validation

REST API

Swagger UI overview

Typed endpoint contract

401 without a token

Pydantic schemas

Administrator

Administrator navigation

Product catalogue

Search, filter and sort

Add product with image upload

Product details

Edit product

Fleet overview

Ship details and operations

Update ship

Confirm before delete

Register a ship

Port operations log

Operation details

Schedule an operation

Port directory

Port details

All orders

Order details

Update order status

Order line items

Client accounts

Client profile and orders

Role assignment

Create account with a role

Configurable pagination

Employee

Employee navigation

Employees manage the fleet

Employees update operations

Orders without Add Order

Read-only line items

Client

Client navigation

Catalogue as a client

Product details, no management

Read-only port directory

Cart with checkout validation

Cart ready for checkout

Only the client's own orders

Tracking an order