Insight
Building a reliable ActiveSG class update workflow
The recurring collation of PickleGO ActiveSG class information took approximately twenty minutes by hand. The completed workflow reduced it to approximately one minute. Both figures are my practical estimates rather than a formal time study.
Sections on this page
The question this article answers
How was the recurring ActiveSG collation rebuilt within an acceptable running cost?
Drawn from: The PickleGO ActiveSG Apps Script and browser-assisted refresh.
Constraint
The routes that were set aside
Two technical routes were tried during the implementation. Direct server-side access to the ActiveSG internal API returned HTTP 403 through Cloudflare during testing. Jina Reader then introduced an authentication and token dependency and did not offer the long-term reliability the recurring task needed. Recurring cost remained a wider feasibility consideration, since a subscription paid indefinitely to save twenty minutes on each update is difficult to justify at this scale.
The final architecture reads the listing in the user's own browser through Tampermonkey and the PickleGO connector userscript, which avoided both dependencies and avoided a recurring paid scraping service. Google Cloud supplies the OAuth identity and configuration for the Apps Script project, and the Google Auth Platform controls test-user authorisation while the app remains in Testing. Google Cloud sits outside the extraction and data-processing path.
Design
The boundary the design works within
Apps Script (opens in a new tab) runs on Google servers, and the built-in services documentation (opens in a new tab) sets out what it can reach from there. ActiveSG programme cards are rendered dynamically and Apps Script does not operate a full interactive browser tab, so the Tampermonkey connector reads the programme information after the page has rendered in the user's browser. Validation and writing stay with Apps Script through the Spreadsheet Service (opens in a new tab), with a defined handover between the two.
I wrote the Apps Script with AI-assisted coding and configured the access it required. The workflow depends on the configured browser environment, since that is where the extraction runs.
Implementation
What the implementation covers
The refresh is manual and is started from the Sheet, so nothing runs on a schedule. The request, the source and the returned payload are validated, the data is checked before anything is written and concurrency protection prevents overlapping runs from writing over one another.
A programme is set to Closed only on explicit evidence such as Full, registration closed, programme cancelled or programme ended. Where a current reading cannot verify a programme, the previously verified value is retained where that is safe and the remarks record that the latest verification failed. After a write, spreadsheet formatting and dropdown behaviour are restored.
What the checks buy
Class availability changes frequently, so an incomplete reading is a normal event. Preserving verified values and validating before writing keeps a partial reading from degrading a sheet that people work from.