C.Fan

Deploying SuburbLens across three clouds

Just finished wiring up the deployment for SuburbLens, a side project that helps new immigrants and students in Australia size up Sydney and Melbourne suburbs using ABS Census data (housing tenure, community languages, country of birth, education levels).

The fun part was that the three pieces of the stack each wanted a different home, so I leaned into it instead of forcing everything onto one platform:

Frontend → AWS Amplify. The React 19 + TypeScript app builds and ships through Amplify's CI/CD, push to the branch, it builds and deploys. Easy CDN-backed hosting with zero servers to babysit.

AI agent → Fly.io. The LangGraph + LangChain assistant (FastAPI) runs as a container on Fly. It needs to hold a long-lived process and talk to a Postgres checkpointer that persists and summarizes each user's chat history, so a real app server fits it better than functions.

Backend API → AWS Lambda. The .NET 10 Minimal API is stateless, query-only, and spiky in traffic — basically the textbook case for serverless. It sits behind Lambda and scales to zero when nobody's around.

Workflow ≠ Multi-Agent

My graph structure is llm → tools → llm → … → END. The LLM decides which tool to call each step, but the topology is fixed. This is a ReAct Agentic Workflow, which is one agent with tools rather than a multi-agent system.

This distinction sounds pedantic until an interviewer asks "how do your agents communicate with each other?" and I have no answer because there's only one agent.

What I did well:

FastAPI streaming implementation is clean

Tool docstrings: this is how the model decides what to call, so vague descriptions directly hurt quality

System prompt placed before conversation history, prefix caching friendly

Finally I am back.

Okay so here's the deal:

Grocery shopping is expensive and figuring out where to buy what is genuinely annoying. You're either checking two different apps, keeping a mental spreadsheet, or just hoping for the best at the checkout.

So I built Price Peer.

It's a price comparison tool that lets you:

compare grocery prices across stores side by side

search the way you actually talk, like "cheap pasta under $2", powered by AI

track your favourite products and get notified when the price drops

I replaced realtime product matching with a batch pipeline that precomputes matches and stores them in productmatch. Compare endpoints now read cached results only, so the API is faster, cheaper, and more stable.

Today’s progress: I switched the scraper to a Playwright DOM strategy. Direct API calls were blocked by WAF, but the rendered page works fine, so I extract product info from aria-label and filter out bad entries. I also added paging plus light scrolling to catch lazy-loaded items. It’s now stable enough for small-scale capture, and can be scaled by tuning limits.

Core logic:

WoolworthsLowerShelfDomScraperService: open the page, loop pageNumber, optionally scroll, extract a[href*='/shop/productdetails/'][aria-label].

Extract Non-member price / Was from aria-label, drop invalid names and missing prices.

Registered the service and exposed a new API route in ScrapingController.

These days I have made scheduled jobs running on specific days of the week for price tracking and email notification. This includes Quartz mode for local testing and AWS scheduled execution for Lambda deployment, where jobs are dispatched through a unified container entry point using the environment variable.

Another big task in progress is the Admin Monitoring page that collects execution details of scheduled jobs and displays their performance metrics

Admin-only visibility is protected via the AdminOnly authorization policy, based on a JWT email whitelist. Currently available admin endpoints:

/api/admin/schedules → read job_definitions

/api/admin/runs → execution history

/api/admin/stats → aggregated failure rate and duration

The next steps:

Connect the configuration and executing time of the AWS Scheduler and Quartz.

Develop /api/admin/health to gather the overall info.

Develop the frontend pages, including list views, detail views, and statistical dashboards.

Today I finished a full round of work on the wishlist price-tracking feature, from data model to service logic and UI hooks.

What I implemented

Extended the data model for wishlist tracking: added new fields to FavoriteItem and introduced a new FavoritePriceAlert table, with SQL migrations applied in Supabase.

Built the price-tracking service end-to-end: read wishlist → fetch latest prices → detect price drops → send email notifications → persist alert logs, with cooldown and deduplication logic.

Integrated MailKit for email delivery, fixed TLS/port mismatches and sender address requirements, and completed configuration + DI setup.

Added a manual price-check trigger API, so tracking can be executed after the crawler runs.

Fixed an EF Core mapping issue that caused an unexpected FavoriteItemId1 shadow foreign key.

Updated the frontend with two new actions: delete favorite and enable/disable alerts, along with the required backend APIs and DTO updates.

Today’s key takeaways

In EF Core, foreign key configuration must match navigation properties, or shadow FKs may be generated.

SMTP security matters: 465 = SslOnConnect, 587 = StartTLS.

Reliable price alerts usually require both cooldown windows and “price must continue dropping” checks.

Frontend action buttons should always stay consistent with the site’s existing style system (contained / text / uppercase).

This week I went on separating dev and prod deployments for my PriceCompare app. It looked simple at first: deploy Lambda + API Gateway + S3, but I met a chain of issues: 503s from API Gateway, database timeouts, IPv4-only Lambda trying to reach an IPv6-only DB, missing API routes, oversized Lambda packages, and missing IAM permissions for S3/Rekognition.

The fix was a mix of configuration and code: switch to the Supabase session pooler (IPv4 friendly), tighten Npgsql settings, add explicit HTTP routes in the template, add S3/Rekognition permissions, and make AWS clients fall back to IAM role credentials. After that, dev and prod deployments finally behaved consistently.

Happy holiday!

This week I pushed a pretty satisfying milestone on my Price-Compare project.

I wired up an end-to-end flow where you can upload a grocery receipt image, send it through AWS Rekognition for OCR, parse store/date/items, and then run a fuzzy match against the product catalog. The backend now stores both the raw OCR text and the normalized product name, along with a matched product ID when it’s confident enough.

On the frontend, I added a two-step experience:

Review parsed items – after upload, a dialog shows each recognized line with the OCR text and an editable “Final name” field. You can clean up names, remove noise, or add your own rows. Saving writes everything back to the receiptitem table via a new PUT /api/Receipts/{id}/items endpoint.

Add to My Favorites – once the receipt items are saved, a second dialog lets you choose which matched products you want to track in “My Favorites”. It’s optional: you can skip it, or select just a few items to follow over time.

Today’s MVP milestone:

I’ve finished the first three steps of my receipt-processing pipeline:

Upload receipt – users upload receipt images

OCR receipt – OCR extracts raw text from the receipt

Parse product names – product names are parsed from the OCR result

It’s still a very early version, but seeing the pipeline work end-to-end feels rewarding.

Finally I can get back to my own learning after university final exams!

I have been thinking about a new feature: AI-powered Receipt Recognition.

The idea is simple: People buy things every day, but price insights disappear the moment a receipt gets thrown away. So I redesigned the flow:

Users upload a photo of their supermarket receipt

The system runs OCR (Textract / GPT-4o)

It extracts item names, prices, quantities

Then matches them to actual products with fuzzy search

Items get saved under the user’s account

A background tracker monitors future price changes

The user receives alerts when any purchased item gets cheaper

Behind this feature:

New DB models

A JWT-based auth system

S3 storage pipeline

A clean, step-by-step OCR - Review - Save workflow

Hosting a React App on AWS S3 - The Simple Way

Today I deployed my React frontend using AWS S3 static website hosting, without CloudFront. The goal was to make a clean, lightweight setup for testing and demos.

Key steps I followed:

Create a private S3 bucket

Disable “Block all public access” and enable Static website hosting

Set both Index and Error document to index.html

Upload build files using: npm run build aws s3 sync build s3://pricecompare-frontend-prod --delete

Add a public-read bucket policy so the site can be accessed externally.

Building “Agentic AI for Hospital”: Our Intelligent Triage System at USYD!

Over the past few weeks, our team built a backend system called Agentic AI for Hospital, an AI-powered triage and hospital resource management platform.

It’s part of our Software Engineering course, but we designed it with real-world scalability and modularity in mind.

Agentic AI for Hospital is a backend service that simulates how an intelligent hospital system could:

Analyse patient symptoms

Classify urgency levels

Generate diagnosis reports through an AI or rule-based NLP engine

Allocate doctors, rooms, and medical resources dynamically

After countless build errors and 250 MB layer limits, I switched two Playwright-based jobs to containerized Lambda functions. Now, both Coles and Woolworths scrapers run in AWS Lambda containers built from .NET 8.

Lessons learned: - Zip for light APIs, Containers for heavy jobs - Use LambdaEntryPoint for unified entry - ECR is smoother once you set up tagging properly