Persistent school data
Move core application data into PostgreSQL so it can be stored and retrieved reliably.
Case Study · 02
School Management System
A Go-based backend system for managing core school operations with PostgreSQL and JWT-protected API routes.
01 · Overview
Building a structured backend for school operations.
The School Management System is a backend application built strictly with Go, with PostgreSQL providing persistent data storage.
The system is designed around core school operations including students, admissions, classes, fees, and academic results.
Authentication and protected API routes were implemented with JWT-based authorization, giving the system a clear foundation for controlling access to backend resources.
Technology
GoPostgreSQLJWTREST APIbcrypt
02 · The Problem
Building a backend foundation for a growing school management system.
The project started with the need for a structured backend capable of managing core school data rather than relying on disconnected or temporary application state.
The system needed persistent storage for users, students, and subjects, while also establishing authentication and protected access to backend resources.
The longer-term goal is to expand this foundation into a broader school management platform covering academic results, grading, termly reports, broadsheets, fees, and administrative workflows.
The challenge was therefore to build the backend incrementally while keeping the foundation structured enough to support those future capabilities.
User authentication
Provide registration and login functionality while protecting user credentials with bcrypt.
Protected resources
Use JWT-based authentication to control access to protected API routes.
Student management
Establish backend functionality for creating and retrieving student records.
Subject management
Establish backend functionality for creating and retrieving subjects.
Future academic workflows
Create a foundation that can later support results, grading, reports, broadsheets, fees, and administrative features.
03 · Architecture
A Go backend connected to persistent PostgreSQL storage.
The system is built with Go and uses the standard net/http package for handling HTTP requests. PostgreSQL provides persistent data storage, with lib/pq used to connect the Go application to the database.
Authentication is handled through bcrypt password hashing and JSON Web Tokens (JWT). Protected API resources require a valid authentication token.
Request flow
Client
↓
Go HTTP API · net/http
↓
JWT Authentication / Protected Routes
↓
PostgreSQL · lib/pq
Go HTTP layer
The backend uses Go's net/http package to handle HTTP requests and expose API functionality.
PostgreSQL
Persistent application data is stored in PostgreSQL rather than being kept only in application memory.
Password security
User passwords are hashed with bcrypt rather than being stored as plain text.
JWT authentication
Authenticated users receive JWT-based credentials that are used when accessing protected resources.
04 · Engineering Challenges
The difficult part was making each layer work together reliably.
Building the system was not a straight line from database design to working API. Several implementation problems appeared along the way, particularly around database access, authentication, routing, and debugging API behavior.
Instead of treating those problems as failures to hide, I used them as part of the development process: identify the failure, trace it back to its source, make the correction, and verify the result.
Database connectivity and permissions
Connecting the Go application to PostgreSQL exposed configuration and database permission issues that had to be diagnosed before the API could reliably interact with persistent data.
Authentication implementation
JWT authentication required making decisions around token generation, signing, and protected API access rather than treating authentication as an afterthought.
Protected API routes
Authentication middleware had to be integrated with the API so that protected resources could distinguish authenticated requests from unauthenticated ones.
Debugging API failures
Some endpoints did not work correctly on the first implementation. Debugging involved tracing requests through the Go server, checking the database interaction, and correcting the underlying implementation.
Small mistakes with visible consequences
A simple naming mistake in the project affected how a status value was displayed. Finding the typo, correcting it, and refreshing the application reinforced the importance of checking the complete data flow rather than assuming the backend response is correct.
Building the backend taught me that debugging is not separate from engineering. It is part of the process of understanding how the system actually behaves.
05 · Current Implementation
The backend foundation is working; the academic platform is still growing.
The current implementation focuses on establishing the core backend capabilities required for the larger school management platform. Authentication, database persistence, student management, and subject management are currently implemented.
User registration
ImplementedUsers can register through the Go backend, with passwords protected using bcrypt hashing.
User login
ImplementedThe backend authenticates users and generates JWT credentials for authenticated sessions.
JWT-protected routes
ImplementedProtected API resources require valid authentication credentials before they can be accessed.
PostgreSQL persistence
ImplementedThe application connects to PostgreSQL and uses persistent database storage for its backend data.
Student management
ImplementedThe current API supports creating and retrieving student records.
Subject management
ImplementedThe current API supports creating and retrieving subject records.
Current API foundation
Authentication
JWT authorization
Student records
Subject records
PostgreSQL
Go REST API
06 · Roadmap
Expanding the backend from its foundation into a complete academic workflow.
The current implementation establishes the authentication, persistence, student, and subject foundations. The next stages focus on building the academic and administrative workflows on top of that foundation.
Result management
Introduce backend support for recording and managing student academic results.
Grade calculation
Build the grading logic required to convert student scores into academic grades.
Term-based results
Organize academic results across first term, second term, and third term within an academic session.
GPA and CGPA
Introduce GPA and cumulative GPA calculations based on the system's academic grading structure.
Broadsheet generation
Generate broader academic reports that allow administrators to review student performance across subjects.
Excel score uploads
Support importing student scores from Excel files to make large-scale result entry more practical.
Fees management
Extend the backend to support school fee records and related financial workflows.
Admin dashboard
Provide an administrative interface for managing students, subjects, results, and other school resources.
Role-based access control
Introduce differentiated permissions for administrators, teachers, and students.
Academic workflow
Subjects→
Scores→
Grades→
Term 1→
Term 2→
Term 3→
GPA→
CGPA→
Broadsheet
07 · Evidence
Explore the implementation.
This case study documents the engineering direction and current state of the project. The repository contains the actual Go backend, authentication implementation, PostgreSQL integration, student and subject functionality, and the ongoing development work.
Repository
School Management System
Explore the Go source code, PostgreSQL integration, authentication implementation, and project documentation.
View repository →Stack
Backend technologies
Gonet/httpPostgreSQLlib/pqJWTbcryptREST API
The project is intentionally being developed incrementally, with the current backend foundation serving as the base for the larger academic and administrative workflows planned for the system.