Hacker News new | ask | show | jobs
by OutOfHere 636 days ago
A cache is better when it's local rather than on the web. And I certainly don't need to pay anyone to cache local request responses.
2 comments

How would one achieve something similarly locally, short of just running a proxy and stuffing the request/response pairs into a DB? I'm sure it wouldn't be too terribly hard to write something, but I figure something open source already exists for OpenAI-compatible APIs.
Recently did this workflow.

Started with nginx proxy with rules to cache base on url/params. Wanted more control over it and explored lua/redis apis, and opted to build a app to do be a little more smart for what i wanted. Extra ec2 cost is negligible compared to cache savings.

Yes! It's amazing how many things you can do with lua in nginx. I had a server that served static websites where the files and the certificates for each website were stored in a bucket. Over 20k websites with 220ms overhead if the certificate wasn't cached.
There are any number of databases and language-specific caching libraries. A custom solution or the use of a proxy isn't necessary.
As I understand it, your data remains local, as it leverages your own database.
Why do I even ha e to use this saas? This should be a open source lib or just a practice that I implement myself.
Implement it yourself then and save your $$ at the expense of your time.
If you factor in dealing with somebody's black box code 6 months into a project, you'll realise you're saving both money and time.
It's not complicated as you make it. There are numerous caching libraries, and databases have been a thing for decades.
Like this is not a big thing to implement, that's my point. There are already libraries like OpenLLMetry and sink to a DB. We are doing something like this already.
Yes, the ol' Dropbox "you can already build such a system yourself quite trivially by getting an FTP account" comment. Even after 17 years, people still feel the need to make this point.
So they can charge you for it.