https://adriandevera.vercel.app/ Adrian De Vera - Portfolio 2026-08-12T23:59:54.586Z https://github.com/jpmonette/feed Adrian De Vera deveraadrian46@gmail.com https://adriandevera.vercel.app Lead AI Systems & Full Stack Engineer specializing in scalable web applications and autonomous agentic workflows with Next.js, TypeScript, Supabase, and AI agents. https://adriandevera.vercel.app/favicon.svg All rights reserved 2026, Adrian De Vera <![CDATA[Free Antigravity Models in Hermes]]> https://adriandevera.vercel.app/hermes-antigravity-blog 2026-08-09T16:00:00.000Z

Integrating Google Antigravity Models into Hermes Agent: The Complete Guide & Engineering Story

How to get free access to Gemini 3.1 Pro, Gemini 3.5 Flash, Gemini 3.6 Flash, and Claude 4.6 inside Hermes Agent—and how to fix the hidden schema, identity filter, and provider routing bugs.
💡 TL;DR: Google’s Antigravity (Cloud Code Assist) offers generous free tiers for frontier models (Gemini 3.x, Claude 4.6, GPT-OSS 120B). Integrating these models into Hermes Agent via the antigravity-provider plugin requires solving four distinct engineering challenges:
  1. Schema Translation: Sanitizing standard JSON Schema keywords (const, oneOf, $ref) for Gemini's strict functionDeclarations.
  1. Identity Scrubbing: Neutralizing a secret Google upstream prompt classifier that returns a masked 429 RESOURCE_EXHAUSTED whenever system instructions contain "You are Hermes Agent...".
  1. Provider Resolution: Bridging Hermes’ runtime plugin registry with resolve_provider_full() to eliminate Unknown provider 'antigravity' errors during model switching.
  1. Wire Model Mapping: Dynamically mapping reasoning effort levels (low, medium, high) to Google's expected wire model IDs (e.g. gemini-3.6-flash-high).
This guide covers the complete setup, architectural breakdown, and step-by-step fixes to get Antigravity running seamlessly in Hermes.

1. Introduction: Why Google Antigravity + Hermes Agent?

If you use tools like omp (Oh My Pi), you are likely familiar with Google Antigravity: free, high-throughput access to frontier AI models including Gemini 3.1 Pro, Gemini 3.5 Flash, Gemini 3.6 Flash, Claude 4.6 (via Google), and GPT-OSS 120B.
For developers who use Hermes Agent (by Nous Research) as their primary terminal coding assistant, bringing Antigravity into Hermes is a huge win—it unlocks powerful, zero-cost reasoning and coding models directly inside Hermes’ rich tool-calling and memory environment.
Hermes supports custom model providers via plugins. The antigravity-provider plugin serves as an in-process bridge, translating OpenAI-formatted chat completions into Google’s Cloud Code Assist API (v1internal:streamGenerateContent).
However, bringing these two systems together out of the box leads to immediate failures. Here is the full guide to getting it working.

2. Quickstart & Installation Setup

Getting the plugin running requires three setup steps:

Step 1: Install the Plugin in Editable Mode

Because the plugin repository (~/.hermes/plugins/antigravity-provider) uses a Python src/ layout (src/antigravity_provider), Hermes' default launcher shim may fail to locate the package:
This binds the plugin directly into Hermes' venv, ensuring imports persist across authentication refreshes.

Step 2: Authenticate OAuth Credentials

Authenticate your Google account using hermes agy login:
This retrieves your OAuth tokens and stores them securely in the macOS Keychain or ~/.hermes/.

Step 3: Configure config.yaml

Add the antigravity provider block to ~/.hermes/config.yaml:

3. Engineering Deep Dive: Overcoming the Integration Hurdles

Connecting Hermes to Antigravity isn't just a matter of passing credentials—it requires adapting Hermes' OpenAI-style structures to Google's specialized Cloud Code Assist backend.

Challenge 1: Translating Tool JSON Schemas

When Hermes executes an agent session, it exports JSON Schemas for its active tools. Standard Hermes schemas use modern JSON Schema features (const, oneOf, anyOf, $ref, definitions, additionalProperties).
Google’s Gemini API expects minimal OpenAPI / Gemini schema objects. Sending standard Hermes schemas results in HTTP 400 validation rejections:
Solution: Update _schema() in transform.py to recursively strip non-compliant schema keywords before translating tools upstream:

Challenge 2: Unmasking the Identity 429 Filter

With schemas sanitized, requests reached Google’s API... but every full agent turn immediately failed with a 429 RESOURCE_EXHAUSTED error:
A standard HTTP 429 implies rate limits or zero quota. However, testing the exact same OAuth credentials inside omp succeeded instantly.
I extracted the OAuth tokens and tested requests using Hermes' request builder:
  • Minimal Request ("Reply with: OK"): HTTP 200 OK
  • Full Agent Request (19KB system prompt + 36 tool definitions): HTTP 429
Small requests worked, so quota wasn't exhausted. Furthermore, sending a dummy 30KB system prompt with all 36 tools also returned HTTP 200 OK, proving total payload size was not the trigger.
The failure was content-dependent.
By systematically binary-searching Hermes’ 19,000-character system prompt line by line against the live API, I isolated the exact sentence causing the 429 rejection:
Testing variations of this sentence confirmed the behavior:
System Instruction Variation
API Result
"You are Hermes Agent."
✅ 200 OK
"You are an intelligent AI assistant created by Nous Research."
✅ 200 OK
"You run on Hermes Agent (by Nous Research)."
✅ 200 OK
"You are Hermes Agent, an intelligent AI assistant created by Nous Research"
❌ 429 EXHAUSTED
"You are Hermes Agent, an intelligent AI assistant created by X Corp"
✅ 200 OK
"You are a Helpful Agent, an intelligent AI assistant created by Nous Research"
✅ 200 OK
Google’s Cloud Code Assist API runs an upstream classifier that filters out system instructions asserting a competing assistant identity. When triggered, the API returns a masked 429 RESOURCE_EXHAUSTED status code rather than a standard policy error.
omp avoids this because it injects Google's own identity line ("You are Antigravity, a powerful agentic AI coding assistant designed by the Google Deepmind team...").
To fix this in Hermes without altering behavioral instructions, I added a targeted regex scrubber in transform.py:
Applying this scrub restored immediate HTTP 200 OK responses while preserving all of Hermes' tool guidance, formatting rules, and session memory.

Challenge 3: Solving Hermes' Dual Provider Resolution System

With single-shot requests working (hermes -z), running hermes model or switching models in the TUI (/model) raised:
Hermes maintains two distinct provider resolution paths:
  1. resolve_runtime_provider(): Used for execution. It queries the in-memory plugin registry where register_provider_profile() registers AntigravityProfile.
  1. resolve_provider_full(): Used by hermes model, TUI /model, and switch_model(). It queries:
      • Config file (providers: block in config.yaml)
      • Built-in aliases (get_provider)
      • Saved custom providers
      • models.dev catalog
Because resolve_provider_full() does not query the runtime plugin registry, explicit provider switches to antigravity failed.
Adding providers.antigravity to config.yaml bridges resolve_provider_full() while leaving resolve_runtime_provider() to execute via the plugin registry.
To ensure this works out-of-the-box for all users, I updated _select_model() in antigravity_provider/hermes_plugin.py to write this section automatically whenever hermes agy select runs:

4. Supporting New Models: Gemini 3.6 Flash & Wire Mapping

Google periodically updates its model lineup (e.g. introducing Gemini 3.6 Flash). However, sending a raw wire model string of gemini-3.6-flash returns 404 NOT_FOUND.
Google's API requires an explicit reasoning effort suffix on the wire:
  • gemini-3.6-flash-low
  • gemini-3.6-flash-medium
  • gemini-3.6-flash-high
To support google-antigravity/gemini-3.6-flash in Hermes, I updated models.py in the plugin to translate Hermes' reasoning effort settings into Google's wire model IDs:
Now, selecting google-antigravity/gemini-3.6-flash in Hermes automatically routes requests to the correct Google wire target based on your active reasoning effort knob.

5. Usage Tracking & Session Insights

A common question when integrating custom providers is whether usage analytics are preserved.
Hermes logs all token usage into ~/.hermes/state.db under billing_provider='antigravity':
Running hermes insights aggregates these tokens alongside your paid API providers.
📌 Note on Quota vs. Usage: omp includes a custom UI meter that polls Google's internal fetchUsage API to show remaining daily allowance. Hermes logs spent tokens per session locally.

6. Verification & Working Examples

Here is how to test and verify your Antigravity integration across Hermes CLI and python environments:

1. Terminal Smoke Tests

2. Programmatic Model Switching Test

7. Developer Checklist for Custom Provider Plugins

When developing or integrating custom model provider plugins into Hermes, keep this checklist handy:
Happy coding with free frontier models in Hermes! 🚀
]]> <![CDATA[Reverse Engineering Antigravity Models Auth]]> https://adriandevera.vercel.app/antigravity-models 2026-08-09T16:00:00.000Z

The Mystery of the 429: How a Single Sentence Broke Google’s Free AI Models in Hermes Agent

Reverse engineering wire protocols, binary-searching system prompts, unmasking a secret identity filter, and bringing Gemini 3.6 Flash to Hermes Agent.
💡 TL;DR: Trying to use Google’s free Antigravity models (Gemini 3.1 Pro, Gemini 3.5 Flash) in Hermes Agent kept throwing 429 RESOURCE_EXHAUSTED errors, even with 100% quota remaining. The culprit wasn't rate limits or payload size—Google's API silently rejects requests whose system prompt contains the sentence "You are Hermes Agent, an intelligent AI assistant created by Nous Research". Neutralizing that single identity line instantly restored full access.
In this post, I cover how I uncovered the filter, sanitized JSON Schemas, fixed Hermes' dual provider resolution system, and wired up full support for the new Gemini 3.6 Flash with reasoning effort mapping.

1. The Dream: Free Frontier Models in Hermes

If you’ve used omp (Oh My Pi), you know the magic of Google Antigravity: direct, zero-cost access to Gemini 3.1 Pro, Gemini 3.5 Flash, Gemini 3.6 Flash, Claude 4.6 via Google, and GPT-OSS 120B.
I do most of my heavy daily coding inside Hermes Agent (by Nous Research). Naturally, I wanted the same free model access in Hermes. Fortunately, Hermes supports third-party provider plugins via antigravity-provider, an in-process bridge that translates OpenAI-formatted chat completions into Google’s Cloud Code Assist API (v1internal:streamGenerateContent).
I installed the plugin, set provider: antigravity, selected google-antigravity/gemini-3.1-pro, and ran a quick smoke test.
That’s when the headaches started.

2. Chapter 1: The Setup Bosses (Imports & Schemas)

Before hitting the main boss, I had to clear two preliminary hurdles.

Hurdle 1: The Invisible Plugin

On the first run, Hermes crashed before making a network call:
The plugin repository used a standard Python src/ layout (src/antigravity_provider), but Hermes' plugin loader generated an import shim that couldn't locate the package inside the virtual environment.
  • The Fix: Installing the package in editable mode (pip install -e ~/.hermes/plugins/antigravity-provider) permanently bound the module to Hermes’ venv, surviving any future hermes agy login shim regenerations.

Hurdle 2: Schema Indigestion

Once the plugin loaded, requests reached Google’s Cloud Code Assist endpoints—only to instantly bounce with 400 Bad Request validation errors:
Hermes exports rich, expressive JSON Schemas for its tools, using standard keywords like const, oneOf, anyOf, $ref, and additionalProperties. Google’s Gemini function declaration parser, however, demands strict, minimal schemas.
  • The Fix: I added a recursive schema sanitizer in transform.py to strip unsupported JSON Schema keywords before sending tool definitions upstream:

3. Chapter 2: The Ghost 429 Quota Error

With schemas sanitized, requests were finally formatted correctly. But now, every single attempt failed with a brick wall:
A standard HTTP 429 usually means one thing: you're out of quota.
Except I wasn't.
I opened omp on the exact same machine, running on the exact same Google OAuth accounts, and executed prompts against Gemini 3.5 Flash without a single hitch. Both accounts showed 100% free quota remaining.
Why would omp work flawlessly while Hermes failed every single time?

4. Chapter 3: Reverse Engineering omp

To find out what omp was doing differently, I dug into ~/.omp/ and inspected its compiled binary:
  1. Multi-Account Rotation: omp maintains four Google OAuth accounts inside SQLite (~/.omp/agent/agent.db), automatically rotating when one gets throttled.
  1. Wire Protocol Parity: omp talks to the exact same endpoint (https://daily-cloudcode-pa.googleapis.com/v1internal:streamGenerateContent?alt=sse) using the exact same request envelope (requestType: "agent", userAgent: "antigravity", ideType: "ANTIGRAVITY").
The wire protocol was 100% identical.
I extracted the OAuth tokens from omp's database and ran isolated test requests using Hermes' Python client:
  • Small Prompt ("Reply with exactly: OK"): HTTP 200 OK (worked on all 4 accounts across both endpoints).
  • Full Hermes Agent Prompt (19KB system prompt + 36 tool schemas ≈ 41KB): HTTP 429 RESOURCE_EXHAUSTED (failed on all 4 accounts).
Small prompts worked, but full agent prompts failed. That meant it wasn't an account-level quota issue. It was deterministic based on the request payload itself.

5. Chapter 4: The Rabbit Hole — Bisecting the System Prompt

Was it payload size?
I generated a dummy 30KB system prompt packed with 36 heavy tool definitions and sent it. HTTP 200 OK.
Size wasn't the issue. The failure was content-dependent.
I began binary-searching the real 19KB Hermes system prompt line by line, testing slices against the live API. Eventually, I narrowed the failure down from 19,000 characters to a single sentence:
If that sentence was present in the system prompt, Google's API returned HTTP 429 RESOURCE_EXHAUSTED. If I modified a single word, it succeeded.

The Bisect Matrix

Here is what happened when I tested variations of that sentence:
System Instruction Variation
API Result
"You are Hermes Agent."
✅ 200 OK
"You are an intelligent AI assistant created by Nous Research."
✅ 200 OK
"You run on Hermes Agent (by Nous Research)."
✅ 200 OK
"You are Hermes Agent, an intelligent AI assistant created by Nous Research"
❌ 429 EXHAUSTED
"You are Hermes Agent, an intelligent AI assistant created by X Corp"
✅ 200 OK
"You are a Helpful Agent, an intelligent AI assistant created by Nous Research"
✅ 200 OK

The Revelation 🤯

Google’s Cloud Code Assist API has an upstream filter that intercepts system instructions asserting a competing assistant's identity. When triggered, instead of returning a standard policy error, the API returns a masked 429 RESOURCE_EXHAUSTED.
omp never ran into this because it injects Google's own identity string ("You are Antigravity, a powerful agentic AI coding assistant designed by the Google Deepmind team...").
Hermes' prompt opens with "You are Hermes Agent, an intelligent AI assistant created by Nous Research"—meaning every single real Hermes prompt was getting caught in Google's identity filter.

The Fix

I added a light regex scrubber to transform.py:
The moment that scrub went in, the full 41.8KB prompt returned HTTP 200 OK. All of Hermes’ tool guidance, memory rules, and formatting instructions remained 100% intact—only the brand identity line was sanitized.

6. Chapter 5: The Dual Provider Resolution Architecture

With prompts working in one-shot mode (hermes -z), I tried switching models in the TUI (/model) and CLI (hermes model). Immediately, a new error popped up:
Why did -z work when model switching failed?
Hermes uses two different provider lookup functions:
  1. resolve_runtime_provider(): Used for execution. It queries the in-memory plugin registry where register_provider_profile() registers AntigravityProfile. This is why z worked.
  1. resolve_provider_full(): Used by hermes model, /model in the TUI, and switch_model(). It searches:
      • Config file (providers: in config.yaml)
      • Built-in provider aliases
      • Saved custom providers
      • models.dev catalog
Because resolve_provider_full() never checks the runtime plugin registry, passing explicit_provider="antigravity" returned None, crashing the model switcher.

The Fix

The error message prescribed the exact fix: add antigravity to ~/.hermes/config.yaml under providers::
To make this permanent for all new setups, I patched _select_model() in the plugin (antigravity_provider/hermes_plugin.py) to auto-populate this section whenever hermes agy select runs:

7. Chapter 6: Adding Gemini 3.6 Flash Support

With the foundation solid, I wanted to add support for Gemini 3.6 Flash.
However, sending a raw model ID of gemini-3.6-flash returned 404 NOT_FOUND. Google’s Cloud Code Assist API requires a reasoning effort suffix (-low, -medium, or -high) on the wire for 3.6 Flash:
  • gemini-3.6-flash-low
  • gemini-3.6-flash-medium
  • gemini-3.6-flash-high
I updated the plugin’s models.py to declare google-antigravity/gemini-3.6-flash in KNOWN_MODELS and map Hermes’ reasoning effort knob to the correct wire model ID:
Now, selecting google-antigravity/gemini-3.6-flash dynamically maps reasoning effort levels (low, medium, high) directly to Google's expected wire model identifiers.

8. Chapter 7: Usage & Analytics

Does Hermes track usage for Antigravity models?
Yes! Hermes logs all token usage into ~/.hermes/state.db under billing_provider='antigravity':
Running hermes insights cleanly aggregates these models alongside your paid providers.
📌 Note: The only difference between omp and Hermes here is that omp queries Google's internal fetchUsage API to render a live "remaining daily quota" meter. Hermes logs spent tokens per session locally.

9. Chapter 8: The Moment of Truth

With all fixes and features in place, I ran full end-to-end verification:

1. Terminal Smoke Tests

2. Programmatic Model Switching Test

]]> <![CDATA[On-Site Face Verification & Multi-Tenant Payroll System]]> https://adriandevera.vercel.app/nunez-dental-clinic-payroll-system 2026-06-23T16:00:00.000Z

On-Site Face Verification & Multi-Tenant Payroll System

A full-stack, enterprise-grade payroll and biometric attendance solution built with Next.js 15, Supabase (Postgres), Drizzle ORM, and Flutter.
The system combines an on-device biometric mobile kiosk app with a multi-tenant web administration portal.

1. Problem & Challenge

Traditional payroll systems rely on manual timecards, badge swipes, or web-based timekeeping prone to buddy punching (employees clocking in for one another) and location fraud.
Client companies needed:
  • Zero-Trust Attendance Verification: Fraud-proof biometric verification directly at physical work sites.
  • Offline-First Kiosk Reliability: Ability to clock in/out during network drops or remote site shifts.
  • Multi-Tenant Isolation: Complete data isolation between client companies from a single deployment.
  • Compliant Philippine Payroll Engine: Automated calculations for daily/monthly rates, overtime rates, and statutory contributions (SSS, PhilHealth, Pag-IBIG).

2. System Architecture

The solution consists of two primary components communicating with a centralized Supabase/Postgres backend:

A. Companion Mobile Kiosk App (`/mobile_app` — Flutter)

  • **On-Device Biometrics:** Powered by Google ML Kit (face detection) and MobileFaceNet (TFLite) for local 192-dimensional vector embedding generation.
  • **Privacy-First Face Matching:** Facial recognition runs entirely on-device; biometric vector embeddings are never sent to external third-party cloud AI APIs.
  • **Biometric Liveness Verification:** Multi-angle head pose detection (blinking, smiling, turning) to prevent static photo or video playback spoofs.
  • **Network & Location Guard:** Enforces clock-ins only when connected to verified site Wi-Fi SSIDs or within geofenced GPS boundaries.
  • **Offline Sync & Reconciliation:** Stores encrypted attendance logs locally during connectivity outages and reconciles automatically when connection restores.

B. HR & Payroll Admin Dashboard (`/payroll-system` — Next.js 15)

  • **Multi-Tenant Portal:** Company member roles, location management, and kiosk device pairing via secure pairing codes.
  • **Payroll Processing Engine:** Real-time summary of regular hours, overtime, tardiness, and statutory contribution tiers.
  • **Audit & Evidence Viewer:** Admin review of attendance scan events with captured verification thumbnails and network metadata.
  • **Employee Portal:** Self-service payslip viewer and attendance history.

3. Technical Highlights

1. High-Performance On-Device Face Recognition

By running MobileFaceNet inference locally via TFLite on the Flutter app, biometric verification finishes in <300ms without server roundtrips. Facial embeddings are compared using cosine similarity against locally cached employee face profiles.

2. Multi-Tenant Architecture & Data Security

  • **Row Level Security (RLS):** Enforces strict company boundaries across Postgres tables (`companies`, `employees`, `attendance_logs`, `kiosk_devices`).
  • **Secure Kiosk Provisioning:** Kiosk devices pair with company accounts via short-lived alphanumeric pairing codes and device secret tokens.

3. Automated Statutory Computation Engine

Payroll runs automatically compute:
  • Gross Pay & Overtime Premiums (Regular Overtime, Rest Day, Special Non-Working, and Holiday rates).
  • Philippine Statutory Deductions: Tiered SSS bracket lookup, percentage-based PhilHealth with salary caps, and Pag-IBIG mandatory contributions.
  • Net Pay Calculation & PDF Payslip Generation.

4. Tech Stack Overview

  • **Mobile Kiosk:** Flutter, Dart, Google ML Kit, MobileFaceNet (TFLite), SQLite, Supabase Flutter SDK
  • **Web Portal:** Next.js 15 (App Router), TypeScript, Tailwind CSS 4, DaisyUI 5, Drizzle ORM
  • **Database & Auth:** Supabase PostgreSQL, Supabase Auth, Row Level Security (RLS)
  • **Deployment:** Vercel (Web Dashboard), Docker (Self-Hosted Postgres / Container Host)
*(Note: Proprietary enterprise platform. Specific client credentials, internal API keys, and database connections are excluded for privacy.)*
]]> <![CDATA[Dental Laboratory Management System for Nunez Dental Clinic]]> https://adriandevera.vercel.app/nunez-dental-lab-management-system 2026-06-23T16:00:00.000Z

The Problem

Dental laboratories handle dozens of active cases simultaneously — crowns, bridges, dentures, and retainers. Each item moves through multiple manufacturing stages, assigned to different technicians, and delivered back to specific dentists. Managing this with paper logs or sticky notes quickly leads to lost jobs and missed delivery dates.
Nunez Dental Clinic needed a central hub to manage lab cases end-to-end.

System Capabilities

The Dental Laboratory Management System provides full operational visibility across the lab floor:
  • Case Tracking: Log incoming jobs with patient details, case types, attending dentist, shade specifications, and target due dates.
  • Status Pipeline: Visual Kanban stages (Received -> In Progress -> Quality Check -> Ready -> Delivered).
  • Material & Inventory Tracking: Log materials consumed per case to track stock levels and cost of goods sold.
  • Delivery & Pickup Logs: Record timestamps and courier signatures upon pickup or delivery.
  • Doctor / Client Portal: View pending cases per doctor and track status without calling the lab.

Technical Architecture

Built with Next.js, TypeScript, and Supabase.
  • Real-Time Synchronization: Supabase real-time subscriptions keep the lab floor and front desk synchronized. When a technician updates a case stage on a tablet, the receptionist sees it immediately.
  • Optimistic UI Updates: UI state updates instantly while requests settle in the background, keeping the floor workflow fast for lab technicians handling tools.

Key Design Decisions

Stage Transition Rules

To ensure cases do not skip quality assurance steps, state transitions enforce prerequisite checks (e.g., a case cannot move to Ready until all material consumption logs and QA sign-offs are submitted).

Inventory Deductions

Material usage is linked directly to case completion, automatically decrementing physical stock (porcelain blocks, acrylics, metal alloys) and triggering reorder alerts when thresholds are reached.

Outcome & Impact

The lab team replaced physical paper slips with a single live dashboard. Turnaround tracking helps them spot bottlenecks on the floor before deadlines slip, improving on-time delivery to partnering dentists.
*(Note: This is a private client project built for internal clinic and lab operations.)*
]]> <![CDATA[ISCP ID Generator — Letting Students Build Their Own School IDs]]> https://adriandevera.vercel.app/iscp-id-generator 2026-06-23T16:00:00.000Z

The Idea

Getting an official school ID at the International State College of the Philippines was often a slow process involving manual forms and long wait times. I built the ISCP ID Generator so students could log in, enter their details, and generate a print-ready school ID card directly in their browser.
No graphic design tools required, and no waiting in line.

System Overview & Workflow

1. Student Auth: Sign in with Google OAuth via Firebase Authentication.
2. Information Input: Enter student details (Full Name, Course, Year Level, Student Number, Emergency Contact).
3. Client-Side Rendering: Live interactive preview of the ID card with customizable template themes and photo uploads.
4. Export Options: Instant browser rendering to high-resolution PNG or print-ready PDF.
5. Persistent Profile: Student data is saved in Firestore so returning users can update details or regenerate lost cards without starting over.

Tech Stack

  • Framework: Next.js 13 (App Router)
  • Language: TypeScript
  • Auth & Database: Firebase (Authentication + Firestore)
  • Styling: Tailwind CSS
  • Deployment & CI/CD: Vercel + GitHub Actions

Technical Highlights & Lessons Learned

1. Canvas vs DOM Rendering

To render high-DPI printable ID cards, I experimented with HTML5 Canvas vs DOM-to-Image libraries (`html2canvas` / `dom-to-image`). DOM-to-Image with SVG filters proved best for maintaining sharp typography across different printer resolutions.

2. Next.js App Router with Firebase

This project served as an early deep dive into the Next.js App Router architecture. I learned how to manage Firebase client SDK instances across client components while keeping API routes clean.

Source Code

The project is open source and available on GitHub: github.com/Adrian-stuff/iscp-id-generator
]]> <![CDATA[ThinkLog - A centralized hub for developer article]]> https://adriandevera.vercel.app/thinklog 2026-05-18T16:00:00.000Z

Building ThinkLog — A Centralized Hub for Developer Articles

ThinkLog is a full-stack web application that aggregates articles from engineering blogs, community platforms, and developer sites into a single fast stream. Instead of hopping between a dozen bookmarks, users get a clean feed with built-in full-text search, syntax-highlighted code blocks, and inline discussions.
Built for Web Systems & Technologies and Quantitative Methods at Pamantasan ng Lungsod ng Valenzuela, ThinkLog demonstrates modern full-stack development using a lightweight, performant frontend architecture.

Tech Stack & Architecture

  • Frontend: Alpine.js, Tailwind CSS (CDN), Highlight.js
  • Backend: Node.js (Express)
  • Database: PostgreSQL (via Supabase)
  • Authentication: Supabase Auth (Email/Password, Google OAuth, GitHub OAuth)
  • RSS Processing: Custom RSS parser with `@extractus/article-extractor`
  • Hosting: Vercel

Key Features

Aggregated Feed & Filtering

Pulls articles from multiple RSS sources into a responsive card layout. Users can filter by source publication and sort by Recommended, Latest, Popular, Trending, or Discover.

Full-Featured Article Reader

Clicking any article opens a dedicated reader view with parsed article body text, syntax-highlighted code blocks with one-click copy, author metadata, and original source links.

Community & Social Features

  • Reactions: Like, Love, or Insightful reactions per post.
  • Inline Comments: Discussion threads on feed cards and full reader views.
  • Native Sharing: Web Share API integration with automatic fallback to clipboard copy.
  • Live Search: PostgreSQL full-text search with instant autocomplete suggestions.

Engineering & Architecture Decisions

Single HTML File SPA with Alpine.js

The entire frontend is built as a single `index.html` file using Alpine.js for state management and view transitions. No heavy build tools, bundlers, or framework overhead — just lightweight CDN-served reactivity.

Eliminating N+1 Queries via Postgres JSON Aggregation

Rather than firing multiple database queries for posts, authors, tags, and comments, the Express backend utilizes PostgreSQL `json_build_object` and `json_agg` functions. A single database query returns fully formatted JSON payloads ready for client rendering.

Resilient Client-Side Routing

Static hosting on Vercel uses a catch-all rewrite rule to route all traffic to `index.html`. Alpine.js paired with the HTML5 History API manages path changes seamlessly without triggering full page reloads.

Database Schema Overview

Takeaways & Lessons Learned

1. Lightweight SPAs: Alpine.js excels at building interactive dashboards without complex build chains.
2. Server-Side Data Bundling: Database-level JSON aggregation significantly reduces network roundtrips and API latency.
3. Content Extraction: Parsing third-party RSS feeds requires robust HTML sanitization to prevent XSS while preserving formatting.

Live Demo & Code

Live Site: thinklogapp.vercel.app | Source Code: github.com/Adrian-stuff/thinklog
]]> <![CDATA[HOACentralPH — Multi-tenant SaaS Platform]]> https://adriandevera.vercel.app/hoacentralph-project 2025-11-18T16:00:00.000Z

HOACentralPH — Multi-tenant SaaS Platform

HOACentralPH is a SaaS platform designed for Homeowners Associations (HOAs) in the Philippines. It features a multi-tenant architecture that isolates organization data while serving multiple subdivisions from a single unified codebase.

Product Overview & Problem Statement

Many residential subdivisions and HOAs in the Philippines rely on manual record-keeping, paper receipts for monthly dues, and fragmented chat groups for official announcements. This causes bookkeeping errors, poor payment visibility, and compliance friction.
HOACentralPH provides a centralized portal for HOA officers, board members, and homeowners to manage operations, track dues, handle facility reservations, and issue official notices.

Core Features

Multi-Tenant Architecture & Subdomains

  • Custom Subdomains: Each HOA organization gets its own dedicated vanity domain/subdomain (e.g., `greenwood.hoacentral.ph`).
  • Subdivision Landing Pages: Public-facing marketing and information page per HOA.
  • Isolated Tenant Data: Strict tenant query boundaries ensure no cross-subdivision data leaks.

Financial Management & Dues Tracking

  • Automated Invoicing: Generate monthly association dues statements automatically.
  • Payment Processing & Verification: Homeowners submit proof of payment; admins verify and issue digital receipts.
  • Expense & Budget Reporting: Real-time financial ledger tracking income vs. operational expenses.

Community & Operations

  • Facility Booking: Amenity reservation system (clubhouse, basketball court, pool) with conflict prevention.
  • Service Requests & Ticketing: Residents submit maintenance requests or incident reports directly to HOA officers.
  • Announcement Portal: Broadcast official notices via email (Nodemailer) and dashboard alerts.
  • Role-Based Access Control (RBAC): Distinct permissions for Super Admins, HOA Board Members, Staff, and Homeowner Members.

Technical Architecture & Tech Stack

  • Framework: Next.js (App Router)
  • Language: TypeScript
  • Styling & UI: Tailwind CSS, shadcn/ui
  • Database & ORM: Supabase (Postgres) with Drizzle ORM
  • Authentication: NextAuth.js / Supabase Auth
  • Transactional Email: Nodemailer
  • Hosting & Infrastructure: Vercel (Edge Functions & Multi-tenant Routing)

Key Technical Challenges & Solutions

1. Multi-Tenant Subdomain Routing

Using Next.js Middleware, incoming HTTP requests are inspected for custom hostnames/subdomains. The middleware rewrites the internal URL path to match the target tenant route dynamically while preserving clean URLs for users.

2. Tenant Data Isolation with Drizzle ORM & Postgres

Every table contains a `tenant_id` foreign key. Database queries are wrapped in tenant-aware helper functions that automatically inject `WHERE tenant_id = current_tenant`, preventing accidental data exposure across organizations.

Project Status

HOACentralPH is in active development and deployment for initial pilot subdivisions across the Philippines.
]]>