Book catalog
Interfaces for adding, editing, viewing, and deleting books and genres.
04CATALOG & LENDING OPERATIONS
Library Management System.
An administrative application for books, memberships, borrowing, returns, and library reporting.
01 / OVERVIEW
From catalog to circulation.
A library operations application with a Next.js frontend. The public frontend source contains catalog, member, staff, borrow/return, genre, and reporting areas. The existing portfolio identifies NestJS and PostgreSQL as its backend stack.
My contribution
Full-stack development, bringing the interface, business workflow, and data layer together.
02 / THE BUSINESS REQUIREMENT
The problem to solve.
Library administration combines catalog information with people and time-sensitive lending activity. Staff need a clear way to manage the records and follow a book through borrowing and return.
03 / THE APPLICATION
What the system does.
Membership
Member administration and a dedicated member-history view.
Borrowing & returns
Purpose-built borrowing and return dialogs, organized in a circulation area.
Administration
Staff, profile, dashboard, reporting, and permission-aware navigation components.
04 / TECHNICAL ARCHITECTURE
How the layers connect.
01
Presentation
Next.js · Tailwind CSS
Catalog, circulation, membership, and reporting interfaces.
02
Application
NestJS · REST API
Backend stack stated in the original portfolio; frontend API integration exists in the public source.
03
Persistence
PostgreSQL
Relational storage stated in the original portfolio.
05 / ENGINEERING DECISIONS
Deliberate choices.
Give circulation its own workflow
Borrowing and returning are distinct actions with dedicated dialogs, rather than generic edits to a book record.
Keep domain areas consistent
Book, member, genre, and staff operations use reusable interface patterns and a shared layout.
06 / THE TECHNICAL CHALLENGE
Coordinating catalog and circulation tasks.
Staff work across books, memberships, and lending records. Each task needs a clear entry point without losing the wider context.
THE APPROACH
The frontend separates these domains into dedicated routes while retaining a shared navigation and layout. Member history and borrow/return views bring related activity into context.
07 / THE RESULT
A connected application.
A dedicated frontend brings catalog, membership, circulation, and reporting tasks into a consistent administrative interface, with reusable forms and shared navigation.
About this case study’s sources
Frontend structure and Next.js/Tailwind dependencies checked against library-manager-frontend. NestJS/PostgreSQL are retained as owner-reported stack details. Screenshot from the original portfolio.
KEEP EXPLORINGLeave Management System
Let’s discuss your next project