Skip to content
web web-application featured

The Great Apes — Personal Blog

Personal blog featuring articles, a gallery, a PDF reader, and an AI chatbot. Built without frameworks or bundlers — vanilla HTML, CSS, and JavaScript with Vercel serverless functions as the backend.

web │ live · amazthegreatape.fun · ai-integration· firebase· responsive· vanilla-js
The Great Apes — Personal Blog
AI Integration Firebase Responsive Vanilla JS Vercel

A personal blog — "The Great Apes" — live at https://www.amazthegreatape.com/. A static multi-page site with no framework and no build step, where every dynamic capability is added by a serverless function or a Firebase listener rather than by a bundler.

Highlights

  • No framework, no bundler, and that is the design — plain HTML pages plus vanilla JS in an IIFE module pattern. Header and footer are injected at runtime by loadComponent() fetching partial HTML, so navigation is edited once in layout/header.html rather than in every page.
  • A three-layer cache-busting system that actually reaches open tabs — versioned asset URLs (css/style.css?v=…) force a refetch, per-folder Cache-Control headers keep HTML revalidating while versioned CSS/JS cache for seven days, and an ASSET_VERSION constant compared against a no-store version.json triggers exactly one reload. The third layer exists because the first two cannot rescue a tab left open for days or a page restored from bfcache; admin pages are deliberately skipped, since reloading mid-article would discard the draft.
  • Dynamic Open Graph tags without server rendering the whole site — api/artikel.js reads _artikel.html and renders per-article OG meta, with /artikel.html rewritten to it in vercel.json. The generated artikel.html at the repo root is gitignored output, not a source file.
  • A PDF reader that streams from Google Drive — api/drive-pdf.js runs on the Edge runtime and proxies range requests for the pdf.js-based "Pojok Baca" reader, passing Content-Range through; the Edge Response never forwards Content-Length, which is why the range handling is explicit.
  • The AI key never reaches the browser — the chatbot talks to api/chat.js, a server-side DeepSeek proxy. The Firebase config in client JS is public client configuration by design; security rests on database rules, not on hiding it.

Key Features

  1. Articles — writing with comments and reactions backed by Firebase Realtime Database, plus a search endpoint and a content index.
  2. Gallery — photo collections driven by data/galeri.json and Firebase, with lightbox viewing.
  3. Pojok Baca — an in-browser PDF e-reader streaming books through the Drive proxy, so nothing large is committed to the repo.
  4. Chatbot — a DeepSeek-backed assistant reachable from the site, proxied server-side.
  5. Testimonials, portfolio and contact — semi-static content in data/*.json combined with live Firebase records and a kirim-pesan endpoint.
  6. Admin panel — Firebase Auth login gating article, gallery and testimonial management directly from the browser.

Tech Stack

  • HTML + CSS + vanilla JavaScript (ES6, IIFE modules, no framework)
  • Firebase Realtime Database, Auth and Storage (compat SDK v8.10.1, loaded from CDN)
  • Vercel Serverless Functions (api/*.js, native handler(req, res), not Express)
  • Vercel Edge runtime (api/drive-pdf.js streaming proxy)
  • DeepSeek API (chatbot, server-side only)
  • pdf.js (Pojok Baca e-reader)
  • Vercel (hosting, deploys on push to main)

Status & Maturity

Active and in continuous use. There is no automated test suite — verification is a documented manual browser checklist plus one ad hoc Puppeteer script run by hand, never in CI. Local development splits between Live Server for static pages and vercel dev for the api/ endpoints. The line count below is dominated by tracked static assets and written content rather than application logic, and is reported that way on purpose.

Measured Metrics

Commits 125
Date Range 31 Mar 2026 – 11 Aug 2026
Lines of code 93,523 (mostly static asset/content files, not all logic)
Automated tests none