C.Fan

Programmer & Photographer

[cheng-f]

The thing I almost got wrong in my recent interviews

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

[cheng-f]

Daily Share - 40

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

upload your receipt and instantly see if you could've paid less elsewhere no more guessing. no more overpaying. just a cleaner, smarter way to shop. try it now: https://www.price-peer.com

[cheng-f]

Dialy Share - 39

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.

Core pipeline: Exact match → Vector candidates (optional) → Token fallback → scoring → topN persisted. This lays the groundwork for future LLM validation, but the batch system runs without any LLM dependency.

[cheng-f]

Daily Share - 38

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.

[cheng-f]

Today’s circular quay.

[cheng-f]

Daily Share - 37

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.

[cheng-f]

Daily Share - 36

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).

[cheng-f]

Daily Share - 35

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!

[cheng-f]

Somewhere painted by the nature.

[cheng-f]

Daily Share - 34

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.

[cheng-f]

Daily Share - 33

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.

Next, I’ll focus on matching parsed products with real items in the database and letting users confirm the results.

[cheng-f]

Daily Share - 32

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

Scheduled jobs that analyze price drops

[cheng-f]

Daily Share - 31

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.

It’s HTTP-only and not production-secure, but for learning and internal demos, it works perfectly.

[cheng-f]

Daily Share - 30

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

The system uses both rule-based logic and LLM-driven reasoning (via LangChain4j + OpenAI), allowing safe fallback behaviour if the AI model is unavailable.

[cheng-f]

Daily Share - 29

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

Result: Fully working hybrid deployment (SAM + Container Image). Finally, my Playwright bots are cloud-native.

[cheng-f]

Bondi beach.

[cheng-f]

Daily Share - 28

After recovering from the mid-sem exams, I'm finally back.

Day-long fight with AWS Lambda’s 250 MB limit. I split Playwright Chromium into four layers — still too fat. The truth hit me: Lambda Layers were never meant for browsers.

Now I’m trying hybrid: Zip Lambdas for normal APIs Container-based Lambdas for Playwright crawlers

It’s clean, scalable, and still dirt cheap.