trying to interact with the API of my feed reader service and feeling like it was written by aliens
I want to find the subset of feed entries which are:
- unread,
- belong to a particular folder of feeds, and
- older than 𝑥 date
this appears to require requesting a complete list of unread entry IDs, and then either the complete list of entries, or entries for each target feed, OR each individual entry, and then checking they match
entry objects do not have a read state flag, that is entirely the domain of the list of unread entry IDs
and I can see from a database structure perspective why you might do that but also oof ouch ow my application will need to store and compute SO much state
wellllll, I wondered how the feed reader's own web UI handles it and it turns out... it cheats, it just has a bespoke endpoint which returns baked HTML of the unread entries, no futzing with the list of unread IDs, boo
then I realised that the source is published on GitHub, and I had a peek at the source and... it's not doing anything special to achieve that
class UnreadEntriesController < ApplicationController
def update
# there is code in this method but it's not relevant
end
endfeedbin/feedbin/.../app/controllers/unread_entries_controller.rb
so... wait, unread entries are just a normal Rails model? there's no bespoke code for the route the web app uses? hold on a sec, what's the API doing then...
def index
@user = current_user
render json: @user.unread_entries.pluck(:entry_id).compact.to_json
endfeedbin/feedbin/.../app/controllers/api/v2/unread_entries_controller.rb
ah. it is a liar. this is (probably) not a database optimisation at all. they are not stored as a list of IDs at all. they're real database items. wtf.
so that's fun.