Original Summary

I hit the Firebase rate limit while developing my portfolio, and the cause was a dashboard I'd had AI write for me. Some context: I rebuilt my portfolio over a couple of weeks. It logs every interaction to Firebase, including clicks and commands typed into a terminal on the homepage. I also built a personal admin panel to view that data: visits over time, grouped daily, plus activity from different hashed URLs. I gave the AI a very specific description of how I wanted the insights to look, and it built exactly that view. What it ignored was scale. Every time I reloaded the admin page, the code read all the documents iteratively and recursively to assemble the charts. My usage graph in the Firebase console showed the result, and then I hit the rate limit. Fixing the queries wasn't enough. The way I was storing documents didn't match the way I wanted to read them back. I had to redesign the schema mid-project so it could record events efficiently and also serve the views. The redesigned version does far fewer reads and writes. What I took from it: - The AI tools, even with a CLAUDE.md and careful prompts, got me to a barely functional prototype. I ended up doing the architecture myself. - Schema decisions made for writing data can quietly break reading it. Design for both early. - Where and how to cache matters, even on a small personal site. - Vibe coding can cost you productivity if you don't keep it on a short leash. I'm planning a longer write-up on the read/write optimisation and the click tracking side.   submitted by   /u/shravanrevanna [link]   [comments]

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：Reddit · SideProject
  • 发布时间：2026/10/12 20:36:46