@skridlevsky I would make a separate repo. I'll PR the action once its up and modify the code to point to it.
PR #152
4 votes · 4 up · 0 down
4
Total Votes
+4
Upvotes
-0
Downvotes
+4-0
Comments(8)
@henryivesjones, up to you - the tradeoffs are balanced. Noisy git history is on brand for OpenChaos. If you'd rather have a dedicated data repo, I can create one.
@skridlevsky
This will make a quite busy git history in a repo and you probably don't want it to live with any other code.
How would you like to handle?
@skridlevsky
Apparently they do send a SIGTERM signal. https://vercel.com/changelog/vercel-functions-now-support-graceful-shutdown ↗
I designed my implementation around the limitations of a serverless environment and would prefer to keep it that way :)
This will make a quite busy git history in a repo and you probably don't want it to live with any other code.
I'll update the PR to handle the SIGTERM signal to flush. But generally I was fine with the "best-effort" counting. I felt like it worked best around the limitations of the project as it stood.
Update on both points:
I'm setting up a VPS for OpenChaos backend services. Your counter runs as a persistent process there, no more cold start problems. The in-memory approach works exactly as designed on a long-running server.
This also ties into #151 (MCP server), which needs the same persistent process for its caching layer. Both are invited in moving to https://github.com/skridlevsky/openchaos-backend.
Next step is still the same: PR the counter logic + GitHub Action config into that repo. I'll handle VPS setup and deployment.
Love the approach. Using a GitHub repo as the persistence layer is peak OpenChaos energy.
Two things before merge:
1. Backend ownership. I've created https://github.com/skridlevsky/openchaos-backend. Could you PR the GitHub Action config there and update the constants in this PR to point at it? The site shouldn't depend on an external repo for a core feature.
2. Serverless cold starts. openchaos.dev runs on Vercel (serverless). Each request can spin up a fresh instance, there's no persistent process. The in-memory PageCounter singleton and its setInterval flush get garbage collected when the instance goes cold. Under low traffic, most increments would be lost before the 60-second flush fires.
Happy to migrate to a hosting setup that keeps a long-running process (VPS, Render, etc.) if that's what it takes to make this work properly. The visitor counter deserves to actually count.
🤖 OpenChaos Bot
Summary: Implements a page view counter, storing counts as files in a separate GitHub repository and displaying the total on the OpenChaos site. It persists counts to a backend using the Github API.
Files changed: 5 (src/app/layout.tsx, src/components/WebCounter.tsx, src/lib/count/constants.ts, src/lib/count/getCount.ts, src/lib/count/pageCounter.ts)
Vibe: Bravely confronting rate limits with the tenacity of a thousand bots.
All Activity(13)
@skridlevsky I would make a separate repo. I'll PR the action once its up and modify the code to point to it.
@henryivesjones, up to you - the tradeoffs are balanced. Noisy git history is on brand for OpenChaos. If you'd rather have a dedicated data repo, I can create one.
@skridlevsky
This will make a quite busy git history in a repo and you probably don't want it to live with any other code.
How would you like to handle?
@skridlevsky
Apparently they do send a SIGTERM signal. https://vercel.com/changelog/vercel-functions-now-support-graceful-shutdown ↗
I designed my implementation around the limitations of a serverless environment and would prefer to keep it that way :)
This will make a quite busy git history in a repo and you probably don't want it to live with any other code.
I'll update the PR to handle the SIGTERM signal to flush. But generally I was fine with the "best-effort" counting. I felt like it worked best around the limitations of the project as it stood.
Update on both points:
I'm setting up a VPS for OpenChaos backend services. Your counter runs as a persistent process there, no more cold start problems. The in-memory approach works exactly as designed on a long-running server.
This also ties into #151 (MCP server), which needs the same persistent process for its caching layer. Both are invited in moving to https://github.com/skridlevsky/openchaos-backend.
Next step is still the same: PR the counter logic + GitHub Action config into that repo. I'll handle VPS setup and deployment.
Love the approach. Using a GitHub repo as the persistence layer is peak OpenChaos energy.
Two things before merge:
1. Backend ownership. I've created https://github.com/skridlevsky/openchaos-backend. Could you PR the GitHub Action config there and update the constants in this PR to point at it? The site shouldn't depend on an external repo for a core feature.
2. Serverless cold starts. openchaos.dev runs on Vercel (serverless). Each request can spin up a fresh instance, there's no persistent process. The in-memory PageCounter singleton and its setInterval flush get garbage collected when the instance goes cold. Under low traffic, most increments would be lost before the 60-second flush fires.
Happy to migrate to a hosting setup that keeps a long-running process (VPS, Render, etc.) if that's what it takes to make this work properly. The visitor counter deserves to actually count.
🤖 OpenChaos Bot
Summary: Implements a page view counter, storing counts as files in a separate GitHub repository and displaying the total on the OpenChaos site. It persists counts to a backend using the Github API.
Files changed: 5 (src/app/layout.tsx, src/components/WebCounter.tsx, src/lib/count/constants.ts, src/lib/count/getCount.ts, src/lib/count/pageCounter.ts)
Vibe: Bravely confronting rate limits with the tenacity of a thousand bots.