Willes Photography Club

Overview

Problem

A photography club runs on forms, chat messages and spreadsheets. Applications get lost, nobody can confirm who is a real member, and event sign-ups sit in someone's notebook.

Approach

I built one site with a public side and an admin side. People apply online and track their application with a temporary ID. Admins approve members, who then get a permanent ID that anyone can verify. Events, the gallery and the committee are all edited from the admin.

Outcome

Pages

17

Admin screens

7

Data collections

5

Lines of code

~13k

ID stages

2

What I built

• Public pages for home, about, events, gallery, membership and contact
• Online join form that gives each applicant a temporary ID
• Status page to track an application as under review, approved or not approved
• Member verification page to check a membership ID
• Event pages with registration, and an admin list of registrations
• Event carousel and photo gallery with images from Google Drive
• Admin sign-in with Firebase Authentication
• Admin screens for members, events, gallery, executive committee, contact messages and settings
• Member search and sorting by ID and status
• Client-side image compression before upload

Architecture

System architecture

Membership flow

Events

Member verification

Engineering decisions

1. 01A temporary ID before approval

   Applicants get a reference at once and can follow their request. A permanent membership ID is only issued after an admin approves them.

2. 02Verification is public, editing is not

   Anyone can confirm a membership ID. Only signed-in admins can create, change or remove members.

3. 03Images are compressed in the browser

   Photos are shrunk before they are stored. Pages load faster and storage stays small.

4. 04Realtime Database for a small club

   A club's data is small and changes slowly, so a managed database with no server to run is enough.