Hacker News new | past | comments | ask | show | jobs | submit | more dyogenez's comments login

Really curious about this too. react-rails is deprecated, so the choice seems to be react_on_rails or inertia.js.


We usually spend about $60/month at Google anyways, so $100 wasn’t a crazy jump. That could be one left on Cloud Run instance. When it jumped to $300 total after disabling it that’s when I got worried.


I recently had a call with Google and have a sales/solution person I’ve been talking to about moving more services there. I’ll share what happened and see what they say.


This sounds like a solid next step. I’d like to stop storing URLs we don’t control in our DB and share URLs to these images behind a CDN. We could slowly roll that out and update each image url in our database over time with both continuing to work.

I didn’t realize you could do this with a private bucket by granting it access either. That combined with IP throttling at the CDN level might be a good replacement for this and cut out the need for Rails.


Thank you! I was wondering where the 250ms of latency was coming from. I’ll change this up today.


I think you have it right. The signed URLs are a way to giving people an address to the files from our API, then they have call it again to key the keys. I suspect if once we put the files behind a CDN with signed keys, we’ll have even more security here.


This is true. I’d still need a CDN in front of the actual files to prevent that. That’s a takeaway for me from this feedback.


I hadn't thought of that, but I love the idea! How's that work?


Register for an account and create a new item. You can replace files in the item , update the description to indicate what date the snapshot was made and what it contains.

https://help.archive.org/help/managing-and-editing-your-item...

It's a very open platform. Think up what the best format for your data is and upload a compressed zip file or tar.gz of the data.

I'd likely do different archives for images and metadata, so people that want to just process metadata can download that specific data and work on it.

Luckily as you can edit over time, you can experiment and adjust based upon user's feedback.


Nice! Yeah I like the idea of sharing our static book data here on some kind of cadence. I'll pencil this in by the end of the year.


I left off the method that generates the signed URL. It limits the bucket to a specific one per env and blocks some protected folders and file types. I left that out in case someone used it to find an opening to attack.


If this were a business and someone else's money I'd do the same. This is a bootstrapped side project coming out of my own wallet.

If money wasn't an issue, I'd probably just allow people to download images for free.


Good point! My POV assumed some amount of revenue generation.


Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: