Hey Shubham, I can still see the API keys in https://www.runanywhere.ai/web-demo, FWIW. A simple proxy of the request from the frontend to your own API and then to the vendor API would solve this. Also recommend rate limiting on the same. Happy to help if you need further assistance.
Seems like you are leaking an ElevenLabs API key in your web demo. The OpenAI completions endpoint also has the API key in the request header but that seems to already be revoked and is returning a 401.
I love Advent of Code! I have used previous years' problems for my guest lectures to Computer Science students and they have all enjoyed those more than a traditional algorithmic lecture.
I totally agree :) I don't blame Go either. We were already a pure Go shop with a lot of focus on backend and infra systems engineering and were trying to venture into the desktop app market for our device monitoring software. Once we validated our idea with a rather buggy MVP haha, we quickly switched over to Electron and deployed on all 3 desktop OSes properly.
I remember we used https://github.com/getlantern/systray at some point along with some interaction with fyne.io. That said, I do not remember how we managed the lifetime but we did test it thoroughly before deploying to our initial beta users (or so we thought :P). The GC behavior started to happen whenever the app was in the background, which it was supposed to be for the majority of the time.
Been a while since I worked on it but I remember we used https://github.com/getlantern/systray at some point along with some interaction with fyne.io AFAIR.
We built a background daemon as a macOS menu bar app in Go, and the performance was surprisingly bad. The Go bindings for native UI frameworks ended up being massive RAM hogs. When we profiled it, we found that the GC essentially gave up under load, which explained why customers were reporting a simple menu bar app consuming 2.5GB+ of RAM on their Macs. We eventually abandoned the Go approach and switched to Electron. (Not-so) Surprisingly, both the DX and UX improved significantly for our use case. Personally, I’d still prefer Swift/C#/C++ for native desktop work (coming from a Qt C++ background), but given the business constraints at the time, Electron ended up being the most pragmatic choice.