This week, I focused on creating a feed generator that my app will connect to in order to fetch posts for display. BlueSky provided a feed generator starter kit, which I used as guidance. As a result, I was able to build a basic feed generator that my app view can now connect to and retrieve posts from.

The Process

I started by developing a basic understanding of how the feed generator starter kit works. This turned out to be surprisingly challenging, likely because I am still a beginner in app development. It’s easy to get bogged down by small details and difficult to know when to dive deeper versus when to move on. Upon reflection, all I really needed to understand about the feed generator is that it provides one or more algorithms to generate a feed and exposes an endpoint that can be used to retrieve a Skeleton Feed. A Skeleton Feed is essentially just a list of URIs linking to the posts selected by the algorithm. The actual hydration of the URIs—retrieving full post data—will be handled later by whoever is requesting the posts, which in this case is my app view.

My next step was to ensure that the generator was working and to figure out how to interface with it. I hosted it locally and used my browser to make XRPC requests to the generator, verifying that I was getting the expected results. Once that was working, I moved on to the next step: connecting my app to the feed generator.

At this point, I knew I could successfully send requests to my feed generator by directly making XRPC requests, but I wanted to figure out how to use the AT Proto API's getSkeletonFeed() function instead. My goal is to become more familiar with the AT Proto framework, so it made sense to use its built-in functionality. However, figuring out exactly how this function worked took some time because I couldn’t find clear documentation on it. This required some digging into the source code, but eventually, I got it to work.

Finally, I focused on displaying the posts from the feed generator in my app view. With the post URIs in hand, I needed to add them to my database, hydrate them, and then display them. I used the AT Proto API’s getPosts() function to hydrate the post URIs. This step was easier than figuring out getSkeletonFeed() since I had already become more familiar with how these APIs work. Once hydrated, I added the posts to my database and integrated them into my HTML homepage.

Takeaways

As expected, building an application like this requires working with a variety of skills and technologies while encountering different types of challenges. Naturally, I end the week knowing more than I did at the beginning and feeling more comfortable with the work I’m doing.

One area where I see improvement is in reading and understanding code written by others, especially web application code. I imagine that if I had more experience going into this project, I wouldn’t have spent as much time trying to wrap my head around how everything works. A key takeaway is learning what to focus on—understanding the big picture rather than getting lost in every small detail.

I’m also becoming more comfortable with the AT Proto ecosystem. A clear example of this is my improved ability to use its APIs. Additionally, conceptualizing how different entities within the ecosystem interact is getting easier, particularly because I am actively building two interacting entities myself.

Lastly, I’m growing more familiar with both front-end and back-end development. The more I work on these aspects, the easier they become. For instance, I had to use Kysely to insert the posts from the feed generator into my database. On the front end, I modified my homepage to display the posts. At this stage, I don’t need to focus too much on low-level details, thanks to generative AI tools like ChatGPT and the fact that much of the foundational code was provided. However, simply working with the code now will make it easier to handle lower-level details in the future if needed.