Documenting what I did to host more than five terabytes and more than one hundred years of family photos on a raspberry pi.
You can get in touch by any of the following methods:
RabbitMQ Work Queue Graceful Shutdown With Timeout
To make a better user experience I’ll be implementing a work queue to handle tasks that take a long time but are not necessary to be completed before returning a successful API response. The classic example is image processing: we want to let the user know that everything is okay as soon as the file is finished uploading, we don’t want them to have to wait for thumbnails to be created or other background processing to take place....
Handling Image Uploads With Gin and Svelte Dropzone
While I expect most of the file/photo operations to happen via a background sync between the web and archive server and a personal computer where the scanning of physical photographs is happening I also want the website to be used as an ongoing archive which means giving other family members not involved in the archiving process the ability to contribute. This means a simple web form where they can go and upload any digital photographs that they may have (e....
CORS Galore: Using Nginx and Github Actions With Playwright
I was originally designing this project to use a single API service domain but for several reasons (mostly due to issues with CORS and sending credentials cross-domain, but also because it seems likely that third-party cookies might be going away entirely in the future) I have decided to mostly abandon that idea and instead opt for a, perhaps more classic, /api route on the same domain that serves that frontend application....
Local Development with cloudflared
For this project I have to manage multiple domains as we have different entrypoints for different members of the family (read: sides of the family). There’s also the API server which needs to serve requests for these domains as well as manage the authentication in a seamless manner (more on that in a future post). As-is that’s a little challenging during local development unless you spin up multiple versions of the frontend application and treat each port that it runs on as a separate domain/origin....
Repository Layout
I’m a big believer in monorepos so of course for this project I have decided to use a monorepo. I’m keeping everything (code, documentation, infracode, this website!, etc.) in a single repository on GitHub. For the application code itself (both the golang-based backend and the svelte-based frontend) my approach has been for each component to behave as if it was the only thing in the repository. Meaning, that the go.mod, go....