Repository navigation
write-api: implement POST /api/people/:slug/avatar (multipart attachment + image resize) #32
Description
Activity
Heads-up: gitsheets v1.1.0 just shipped useful APIs for this
The avatar route can now lean on first-class attachment APIs instead of poking at internals:
Sheet.setAttachment(record, name, blob)— already existedSheet.deleteAttachment(record, name)— new in v1.1; needed for "replace avatar" / "remove avatar" semanticsSheet.deleteAttachments(record)— new in v1.1; bulkSheet.attachments(record)iterator — new in v1.1; returns{name, mimeType, blob}with.read()(Buffer) and.stream()(Readable) per blob
Together these make the implementation cleaner:
// upload: set the new attachment await tx.public.sheet('people').setAttachment(person, 'avatar.jpg', buffer); await tx.public.sheet('people').upsert({ ...person, avatarKey: 'people/<slug>/avatar.jpg' }); // remove old (if replacing): use the new explicit delete await tx.public.sheet('people').deleteAttachment(person, 'avatar.jpg');
Implementation order should still wait until the deploy plan establishes how multipart uploads land (Fastify
@fastify/multipartis the obvious choice), but the storage-side primitives are now ready.Release notes: https://github.com/JarvusInnovations/gitsheets/releases/tag/v1.1.0
- added a commit that references this issue
on May 30, 2026
Deferred from write-api (PR #29). The plan listed
POST /api/people/:slug/avatarunder People mutations but didn't ship it — multipart attachment handling needs server-side image processing + gitsheetssetAttachmentplumbing that wasn't in scope.Per
specs/api/people.md: max 5 MB, jpeg/png/webp, store atpeople/<slug>/avatar.jpg, with a 128×128 thumbnail.Required pieces:
@fastify/multipartplugin (or equivalent) in the API skeletontx.public.openSheet('people').setAttachment(person, 'avatar.jpg', buffer)per gitsheets APIrequireAuth('self | staff')Person.avatarKeyfield gets set to the attachment key on commit