[ashishb]

As someone who maintains a Music+Podcast app as a hobby project, I intentionally have no servers for it.

You don't need one. You can fetch RSS feeds directly on mobile devices; it is faster, less work to maintain, and has a smaller attach surface for rouge bots.

[arresin]

If you want to do something interesting with the feeds it would be harder.

[ashishb]

> If you want to do something interesting with the feeds it would be harder.

I am curious: What do you do with the feeds that can't be done in a client-side app? An aggregation across all users or recommendation system is one thing, but it can even be done via the clients sending analytics data back to the servers.

[ilyabez]

Hi, I'm the author of the blog (though I didn't post it on HN).

If you want to have a cross-platform experience (mobile + web), you'd have to have a server component.

We do transcript, chapter and summary extraction on the server (they are reused across customers), RSS fetching is optimized (so we don't hit the hosts from all the clients independently), our playlists are server-side (so they can be shared across platforms). As we build out the app, features like push notifications will require a server component too.

I agree with you that a podcast app can be built entirely client-side, but that will be limiting for more advanced and/or expensive use cases (like using LLMs).

[ashishb]

> We do transcript, chapter and summary extraction on the server

Yeah, do this server side but let the clients request it after fetching RSS feeds directly.

And you will reduce both bandwidth usage and increase reliability of your app.

There is no reason to transform images at all IMHO