The Faith Centre Global — Website
The official website for The Faith Centre Global, a church in Okota, Lagos — a static, no-backend site where nearly every piece of content (sermons, events, books, giving, testimonies, leadership) is driven by JSON files, so day-to-day updates never require touching HTML.
3 stars · HTML · updated Aug 19, 2026
The Problem
A church website needs frequent content updates (new sermons, events, announcements) from non-technical staff, without a CMS backend or hosting costs.
The Solution
A multi-page HTML/CSS/Bootstrap 5 site with no build step and no backend, where a JSON content layer (content/ for things that change often, config/ for things that rarely do) is fetched client-side and rendered by a single reusable renderer. js/content-loader.js fetches every content/config file and exposes it globally, firing a ready event; js/render.js listens for that event and renders every section of every page from the data, checking whether each section's container exists before touching it, so one file safely covers every page.
Architecture
Client-side JSON-CMS pattern: content-loader.js (fetch + expose data) → render.js (data-to-DOM rendering, reusable card/list renderers) → script.js (navbar, counters, filters, live search, scroll-to-top — resilient to content injected asynchronously). Also includes a service worker + PWA install banner for offline app-shell caching, and a self-contained floating 'Ministry Assistant' chat widget that matches visitor questions against a separate keyword-based knowledge base (with a marked TODO to swap in a real AI API later). Payments (Paystack), forms (Formspree), and analytics are wired but intentionally left disabled with empty placeholders until the client confirms providers — enabling them is a config edit, not a code change.
Tech Stack
Features
- 10 pages: Home, About, Ministries, Sermons, Events, Books (bookstore w/ WhatsApp checkout), Media Centre, Giving, Livestream, Contact
- Entire content layer JSON-driven — 16 content/config files, zero HTML edits for routine updates
- Self-contained 'Ministry Assistant' chat widget answering common visitor questions
- Installable as a PWA with offline app-shell caching
- Paystack giving, Formspree contact forms, and analytics pre-wired but disabled until credentials are supplied
- Prayer request modal, testimonials, FAQ accordion, live-search
Future Improvements
A documented roadmap (ROADMAP.md) and a FUTURE_SUPABASE.md note on how a database could later power dynamic features beyond the current static/JSON approach.
Engineering Case Study
Architecture
The site needed to be editable by non-technical church staff without a CMS backend, hosting costs, or a build step. The solution is a client-side JSON-CMS pattern split into two layers: content/ (things that change often — sermons, events, books, testimonies, leadership, announcements) and config/ (things that rarely change — payment providers, form endpoints, analytics IDs, social links).
js/content-loader.js fetches every file in both layers on page load and exposes them as window.TFCG_CONTENT / window.TFCG_CONFIG, firing a tfcg:content-ready event once everything's loaded. js/render.js listens for that event and renders every section of every page from that data through reusable card/list renderer functions — each renderer checks whether its container exists on the current page before doing anything, so this one file safely covers all 10 pages without page-specific branches.
Implementation notes
js/script.js(navbar behavior, counters, filter tabs, live search, scroll-to-top) is written to tolerate content being injected asynchronously, since the JSON fetch means the DOM isn't fully populated on first paint.- A floating "Ministry Assistant" chat widget answers common visitor questions by matching keywords against a separate, self-contained knowledge base (
js/church-data.json) — deliberately kept independent from thecontent//config/CMS so it keeps working even if a content file is temporarily broken. The code has a marked// TODO: Swap this function for a real AI API callfor when that upgrade happens. - Payments (Paystack), contact forms (Formspree), and analytics are fully wired in code but shipped with
enabled: falseand empty placeholders in their respective config files — turning any of them on is a config edit, not a code change, once the church confirms which providers to use. - A service worker (
sw.js) plus an install-banner script give the site an installable, offline-capable PWA app shell.
Tradeoffs
Fetching JSON client-side means the site can't be opened directly from disk (file://) — it needs to be served over even a minimal local web server for the fetch() calls to succeed. That's a one-line npm run dev for local development, and no different from any other site in production, so it was an acceptable tradeoff for the much bigger win: zero backend, zero hosting cost beyond static file hosting, and content updates that are a JSON edit instead of an HTML edit — the same architectural bet this portfolio itself is built on.