Okay. My name's Chad Miller. You can find me on Bluesky, ChadCmiller.com. I'm doing a lot of different experimentation with App Views. So a lot of experiments with apps that aren't Bluesky clients or anything related to Bluesky at all, just kind of like you have some custom lexicons and you want to build an app. So I've been doing a lot of experiments with that. What is an app view? If you don't know, it kind of sits in between the relay and the sort of client that you're using. So you have all this information flowing from the all of your records flowing from the PDS through the relay.
The app view sort of is a place that stores all of your records and brings them all together from all the different PDSs across the network. And then sort of hydrate, brings all that data together, hydrates it, so your like counts and your common counts and all that stuff and provides it to your web app or your mobile application to render it on the screen. If we look closer at the app view itself, there's a bunch of things going on. So we have a fire hose connection. But we also need to take into account pretty much all the data that we care about.
So the backfill, that's the backfill portion. So we have some kind of indexer that's going to take in all of these events from the network. You have like commit commits, they're called commit events. So you have creates, updates, deletes. Then you filter those down to what you care about. So you might only care about a um what is the connection lexicon from the uh connection app that we were that everybody's been using. You might only care about that, so that filters through the database, and then you sort of have a hydration layer that's going to request all those and return them via um what in atproto land is called XRPC endpoints.
Really it's just an HTTP endpoint that's typed against your lexicons, so you can define what the responses are in your lexicon uh definitions. And then if we look a little bit closer at the sort of request pipeline, um you'll if you look closer at the app proto repo, you'll sort of see this pattern a lot. Um and you sort of fetch all of the you know, you batch fetch all these records from the database, um, apply some rules to them. This might be some labels that you have, some map um for moderation and you know, bringing all that together, all the the light counts and the comment counts together to return in the JSON response.
Um so where can you get started if you want to build your own app view? Um, the main reference repo is the app proto that is essentially the back end for Bluesky. How many people have spent a lot of time digging through that code? Yeah. There's statusphere but it's pretty basic. It just has like a single crut as just like a create operation, so it's not really like that much going on, and obviously you want your app to be a lot more, you know, a lot richer than Statusphere. Um then we have all the community app views.
So we have like leaflet tangled um, what else is there? Uh margin, there's off print. There's all these app views out there now. Um so there's a lot of good reference places, like depending on which programming language you're into. Um right now it's kind of like you know an art project, so everybody has their own implementation of what you know it says on approto.com and the specs and what they've sort of gathered from the app protopo. Um spent um some time sort of putting patterns together into a service that you can just deploy uh called QuickSlice, and it sort of maps your lexicons to a GraphQL API that you can just query without having to do um a whole lot.
Um and then there's also constellation. There's sometimes you might not need an app view, so um figs APIs provide a way to just get like for example NPMX just wants to show the light count on their on their their packages so they can just use constellation for that. So they don't even need NetView. So what are all the things that you need? You need a way to backfill all of the data on the network. So that is going to be you probably heard a lot about tap. Tap provides a way to filter those collections that you want.
There's also other ways you can parse the card piles manually and have your own process for backfilling. Indexing, so you need some sort of layer to translate the lexicons like the lexicon records into your database. And then there's some kind of code gen aspect which works with the lexicon definitions. Again with the XRP C endpoints. So usually when you're working with lexicons, you want a way to have you know type safe endpoints against those. Generally be nice to have this all figured out for you and you don't have to worry about it. Not really necessary for every application, but there is this concept of the feed generator in Bluesky, which is a separate server that you can run that pretty much just returns the URIs of records that can be picked up by Bluesky to render a feed.
That same pattern can be used in any app proto application. And I'm actually going to show you really in a in a second what that looks like. Labels, obviously, if you want to do some kind of moderation, you're gonna need to have some sort of support for labeling. This can be a simple, just a simple table in your database to make it quick. And then preferences sometimes you want to have data that's stored privately to the app view. And you can sort of just have a preferences table for that. And then open graph. So generally you want to have a way to like share images, image previews back to Bluesky for rendering like a social post.
So I've been sort of playing around with the newer ideas in this framework I call hack. It's sort of like a conventional, like a conventional configuration, although there's still some configuration framework for building an app view. You can sort of attach this app view server to a svelt app. You can check it out at hack.dev. It's pretty early alpha, just sort of playing around with some ideas.
This is the rewrote Grain Social to use all these patterns. It's all open source untangled. There's a bunch of feeds here. So like you can people upload photos and it shows the exit data in a as a feed and locations as a feed. And then there's actually one thing I wanted to point out is there's a great pattern for running your app view locally. A lot of times it's hard to reproduce stuff because there's a lot, you know, there's a lot of stuff that you have to do to bring an app view together, but um there's a pattern in there for running your app locally and having reproducible data that you can use to help build your app.
And yeah, that's all I got.