2,5 weeks into building the backend for my podcast app. I’m not working on it fulltime as I’m working on @Podhomefm for our awesome customers. I now run two databases, a writable one and a read-only replica. This works sooo much better for performance. I run my podping listener in one Function App (Linux, B2 size), and the feed puller in another Function App (Linux, B3 series), because ai found that running it all in one Function app didn’t fit memory-wise. These functions pull RSS feeds into memory to parse them, which is heavy. I’m monitoring the behavior to see if I can scale anything back and fix errors when I run into them. One example is that a feed contained items (episodes) with a duration of -1 seconds. I parse this into a C# TimeSpan, which works, but fails when I save it to the database. Just stuff like that. This backend serves two purposes: 1️⃣ discovery: show users podcasts and episodes they might be interested in 2️⃣ notifications: notify users when a new episode is published for a podcast they are interested in (I still need to build the notification mechanism) Next is more for discovery, before I start with the client app. I want to create an API that I can use to search for podcasts, episodes, people and topics. Ideally this works with my own data, and the Podcast Index API as augmentation (if I don’t have the results myself, so that users can always find a podcast)

Podping, WebSub and pull for podcast updates. For my podcast app, I’m keeping my own database. Just for the purpose of showing users podcasts for discovery, and to be able to send users notifications when something happens like new or live episodes for shows that they are subscribed to. I have my updater running that pulls feeds a couple times a day, and pulls and parses priority feeds (that users are subscribed to) every 30 minutes or less. A lot of feeds use WebSub, which is a publish and subscribe mechanism. This works okay, and I can listen to those updates. But if I miss one (when my service is down, or the hub is down, or because of a transient issue, like a connection drop), I can never get the update again. As this is unreliable, I have no choice but to pull these podcasts periodically. A better way is PodPing. This is a podcast update mechanism that writes podcast updates to the Hive blockchain. Many podcast hosting companies use this now, including us at @Podhomefm. You can listen to updates, which all have a block id, and pick up where you left off when your service restarts or goes down. To get the updates, I can watch the Hive blockchain for Podping messages. I first wanted to listen to a websocket thing that @johnspurlock built, and backtrack with an API when the connection dropped or something. That is inherently unreliable, as I can still miss things m, and it is difficult to get the timings right. Also, I don’t want to rely on another abstraction layer. So I just adapted the C# CHive library, in combination with with a Podping JS library to roll my own C# HivePodpingAPI. That’s the thing in the video. If you’re interested in listening to Podping using C#, clone it, change it, use it from here: github.com/bmaluijb/HivePodp… Next for me is to update RSS feeds that are Podpinged. I’m again going to use Azure Durable Functions for that. Each time a Podping happens, I’ll extract the URLs (feeds) to update, and send those to a worker Function that handles them asynchronously. One thing that I’ve already noticed is that the feeds being Podpinged mostly don’t have the <podcast:podping> tag in them, so they are in my database as feeds that need to be pulled. I’ll update them as they are Podpinged. Almost there with the updating backend.