Samuel
@samuel.fm
would anyone be interested in a talk about backend-for-frontend architecture
14 4 120Samuel*atproto BFF, to be clear. which is something more specific than BFF in general
3 1 27No, in that case 😅
Christopher Jr RileyI don't think I'm qualified enough to speak about that 😅
... yet! (Still converting a bunch of the TypeScript and Go code to Swift. Man is this complicated...)
3
Aaaaaallan DeutschYeah I’d love to get an overview of what’s different about BFF on ATProto
1 2Aaaaaallan DeutschAlso if you want to test run the talk with a smaller, friendly local audience we’d love to host you @seattlejs.com for it!
1 1Samuelheh - unfortunately I live in Europe so bit of a trip! but thanks, very kind to offer :)
1 1Aaaaaallan DeutschIf you ever find yourself on a trip to Seattle, the offer stands!
EmeliaWhat are your thoughts about storage local compute? I wrote about this in regards to Solid because we were seeing BFFs that just accumulated people's data because "talking to a pod is too hard"
1 2Samuelatproto is heavily architected around a hard separation between data hosting and data aggregation/presentation. we want to keep hosting as cheap as possible - going viral shouldn’t cost you money! I suppose in atproto, the appview *is* a BFF, with the PDS network being the “real” backend
3 7Samuelwhat I’m talking about is BFF in the context of atproto - thinner clients, thicker appviews
dan@danabra.mov· 29 Mar 2025these generic APIs often have issues with underfetching (not enough data for a screen, need multiple requests or worse — multiple roundtrips) and overfetching (grabbing more stuff that this particular screen doesn’t actually need). the idea with BFF is to be more tailored “server part of the client”
Emeliayeah, for solid it was this notion that interacting with a pod and lots of small files was hard, where as "stick everything in a huge postgresql database" was easy, but Solid doesn't really have a way to do sync (there is Linked Data Notifications, but that's not really sync)
1 1
Andy IngramFor years I’ve described GraphQL as frontend code that runs on the backend.
EmeliaYeah, for Solid the privacy controls in the pod are really what makes storage-local compute a rather interesting notion — sure, you can always do BFF, but if you're needing to aggregate data or have continuous access to the pod, maybe you're better off paying the pod owner / operator for compute.
1 1EmeliaFor context: forum.solidproject.org/t/why-backen...
(I used to work at Inrupt on Solid)
Why Backend-for-Frontend for Solid is categorically wrong
This is an interesting thread on Inrupt’s Backend-for-Frontend (BFF) blog posting and I’ve learned a bit from the dialog (and I’m still digesting some of the finer points). In reading the BFF blog I ...
forum.solidproject.org
ǝuuɐſhold up, we might have found the Jerry solution
1ǝuuɐſbsky devs: going viral shouldn’t cost you money!
me: make @jcsalterego.bsky.social pay for going viral
1
Kevin Marks
Samueloh I’m thinking for Ahoy (the atproto conf). not sure the nitty-gritty about atproto BFF would be relevant for a non-atproto crowd
2 2Kevin MarksI'd find a real world post-GraphQL discussion interesting, but I may be less completely frontend orientated
1
Ted Han★ 韓聖安Yes I think anything more that helps folks understand how so paradigms change is super useful.
Coffees for ClosersYou filthy bugger!
1
stewleach.bsky.socialIt would be great if you could provide some use-case and definition of what you mean by BFF. I've worked in this area, so I'm interested, but I fear my experience is biasing me towards thinking I know what context you are talking about.
AntonioSure