Interestingly enough, the project’s name in Chinese, 滴 (dī), means “[to] drip” or “a drop of liquid”. I can’t remember why I chose this exact word, but I suspect that college-aged me had some idea of how uploaded images and drops of water relate :)
auspicious (because of the rust implementation)
It was definitely slightly amusing rewriting this in Rust and thinking of std::ops::Drop constantly. Hopefully it doesn’t become a point of confusion at some point!
ironic (because it presumably never deletes uploaded JPEGs?)
I was thinking about adding a DELETE /drops/:drop_id endpoint, as I could certainly see myself wanting to delete a drop (like if I were to upload the wrong file). Right now I just delete files from S3 if I ever find myself with a need to.
you could eliminate the entire read-side cache by responding to GET /drop/<dropid> with a redirect to a generated s3 URL; that’ll remove the need to store stuff locally altogether.
I can’t decide whether the name is auspicious (because of the rust implementation) or ironic (because it presumably never deletes uploaded JPEGs?)
Interestingly enough, the project’s name in Chinese, 滴 (dī), means “[to] drip” or “a drop of liquid”. I can’t remember why I chose this exact word, but I suspect that college-aged me had some idea of how uploaded images and drops of water relate :)
It was definitely slightly amusing rewriting this in Rust and thinking of
std::ops::Dropconstantly. Hopefully it doesn’t become a point of confusion at some point!I was thinking about adding a
DELETE /drops/:drop_idendpoint, as I could certainly see myself wanting to delete a drop (like if I were to upload the wrong file). Right now I just delete files from S3 if I ever find myself with a need to.you could eliminate the entire read-side cache by responding to
GET /drop/<dropid>with a redirect to a generated s3 URL; that’ll remove the need to store stuff locally altogether.This is an interesting idea! I’ll have to play around with it.