Bookings (Monolith)

Bookings is a personal learning project: a server-rendered monolithic web application for room reservations and admin reservation management. It is not production software.

Some admin static assets appear to come from a BootstrapDash / RoyalUI template and should be treated as third-party course/template material.

Learning Goals

• Practice Go web application structure in a monolith
• Learn routing, middleware, sessions, CSRF, and template rendering
• Work with PostgreSQL, SQL migrations, and repository-style data access
• Explore auth flows, admin workflows, and email notifications
• Keep a small project organized for future refactoring and study

Tech Stack

• Go 1.18
• Chi router
• PostgreSQL
• SCS sessions
• Nosurf CSRF protection
• pgx PostgreSQL driver
• bcrypt password hashing
• go-simple-mail for SMTP
• Optional npm/gulp-based admin asset tooling under static/admin

Application Domain

• Room availability search and booking
• Reservation management for an admin user
• Blocking rooms/dates on a calendar
• Login-protected admin actions

Architecture Overview

• Monolith: one Go binary handles routing, business logic, HTML rendering, session state, auth, admin workflows, and database access
• No separate frontend/backend deployables
• Entry point: cmd/web/main.go
• Router & middleware: Chi router in cmd/web/routes.go
• Request handlers: internal/handlers
• Data access abstraction: internal/repository interface
• PostgreSQL implementation: internal/repository/dbrepo/postgres.go
• Rendering layer: internal/render
• Session/auth helpers: SCS sessions + custom middleware
• Templates: templates/*.page.tmpl + *.layout.tmpl
• Static assets: static/
• Migrations: migrations/ (Soda/Pop style)

Project Structure

bookings/
├── cmd/web/                 # main, routes, middleware, mail listener
├── internal/
│   ├── config/              # app config container
│   ├── handlers/            # HTTP handlers and flow orchestration
│   ├── repository/          # DB interface + implementations
│   ├── render/              # template cache/rendering + default template data
│   ├── forms/               # form validation helpers
│   ├── helpers/             # auth + error helpers
│   └── models/              # domain and template models
├── templates/               # public/admin page templates
├── static/                  # CSS/JS/images/admin assets
├── email-templates/         # email HTML templates
├── migrations/              # SQL/Fizz migrations and seeds
├── database.yml.example     # DB config template for migration tool
└── run.sh                   # local build/run script

Main Request Flows

1) Availability search and booking

1. User opens /search-availability.
2. User submits dates (POST /search-availability or JSON variant).
3. App queries room availability through repository methods.
4. Available rooms are rendered in /choose-room/{id} flow.
5. Reservation form (/make-reservation) is submitted and validated.
6. Reservation + room restriction are persisted in DB.
7. Confirmation and owner-notification emails are queued and sent.
8. User is redirected to /reservation-summary.

2) Session-backed reservation state

• In-progress reservation data is stored in session (reservation key).
• Steps like choose-room -> make-reservation -> summary depend on session state and redirect safely on missing data.

3) Authentication and admin access

1. User logs in via /user/login.
2. Credentials are validated against stored bcrypt password hash.
3. Session key user_id is set on success.
4. /admin/* routes are protected by Auth middleware.
5. Admin can view, edit, process, delete reservations, and manage block calendar.

4) Admin reservation calendar/blocking

• Calendar view (/admin/reservations-calendar) builds per-room reservation/block maps.
• POST action updates manual room blocks by adding/removing room_restrictions records.

Running Locally

1. Configure database/runtime flags.
2. Build and run:

go build -o build/bookings cmd/web/*.go
./build/bookings \
  -db-name=bookings \
  -db-user=<db_user> \
  -db-pass=<db_password> \
  -db-host=localhost \
  -db-port=5432 \
  -db-ssl=disable \
  -cache=false \
  -production=false

Server listens on :8080.

Tests

• Run Go tests with go test ./...
• Use the package-level tests already in the repository where present

Configuration / Secrets

From cmd/web/main.go:

• -production bool
• -cache bool
• -db-name string (required)
• -db-host string
• -db-user string (required)
• -db-pass string
• -db-port string
• -db-ssl string

Keep local secrets out of version control. database.yml.example is the sample config; database.yml is local-only.

Notes For Future Study

• Compare this monolith with a split service architecture
• Review how middleware, sessions, and CSRF interact in Go
• Study template composition and reusable layout patterns
• Evaluate whether the admin asset pipeline is still necessary
• Revisit repository boundaries and test coverage as the project evolves

Git / Remote Publishing

• This repo is intended for personal study and GitHub publishing
• Use a normal GitHub remote and push the learning project as-is
• Keep template/course assets credited and clearly separated from original work where appropriate
• Avoid treating the project as a production deployment candidate

Suggested GitHub Topics

• go
• golang
• chi-router
• postgresql
• web-application
• monolith
• sessions
• csrf
• authentication
• reservations
• booking-system
• learning-project
• bootstrapdash
• royalui

Status

• Active learning project
• Monolithic Go booking application
• Not production-ready

Documentation by Area

• Web entrypoint + routes: cmd/web/README.md
• Internal architecture: internal/README.md
• Admin assets/tooling: static/admin/README.md