[DN] Implement API to fetch single story

[ataulm]

We're relying on a cache in StoriesRepository to get the data required to display a Designer News story:

class GetStoryUseCase @Inject constructor(private val storiesRepository: StoriesRepository) {

    operator fun invoke(id: Long): Result<Story> {
        val result = storiesRepository.getStory(id)
        return if (result is Result.Success) {
            Result.Success(result.data.toStory())
        } else {
            Result.Error(IllegalStateException("Story $id not cached"))
        }
    }
}

The cache is populated when retrieving a bundle of stories from the API StoriesRepository.loadStories(page: Int).

If the story is not present in the cache, then we'll return an error.

---

This blocks #436 because it's not possible to populate this cache from the scraped search API because we only get ID and title. The two proposed solutions in that ticket

• chain the search call onto fetching the full data for each of the stories
• (I started working on this one)
  introduce a new StorySearchResult PlaidItem (which only needs ID, title) and defer the fetch until opening the details

each depend on there being an API for fetching an individual story.

[ataulm]

woo the API lets you pass multiple IDs e.g.:

https://www.designernews.co/api/v2/stories/100053,100046

This means the first approach from above is more feasible than it used to be, since instead of 1 + n API requests (where n is the number of search results), it'll be 2 (1 for the search request, and 1 to get the stories) and should result in fewer code changes.

---

In any case though, we'll still need to add another API to DesignerNewsService.

[ZacSweers]

There be dragons here. I wrote about this a bit in a blog post (the designer news section):
https://link.medium.com/shZ1GO6KDT

TL;DR - in my experience, that endpoint basically never worked most of the time. Maybe they’ve improved it though!

[ZacSweers]

Wait ignore me, this is for stories and not for users like I was doing :). That seeeeems like it should be more robust since that’s arguably the most important part of the API. The structure of that impl might still be helpful examples for this though

[ataulm]

Thanks for the heads-up!

I think you're right, the stories endpoint should be more reliable in terms of data we can expect to be there; I guess for users, it's dependent on how much stuff they've filled out?

Is this what you meant by "best effort" or did you mean that the API itself errors out occasionally? (I only tested it a couple of times with Postman)

[ataulm]

This probably didn't deserve its own issue 🙈 since the response is the same, this boils down to adding another few lines:

@EnvelopePayload("stories")
@GET("api/v2/stories")
fun getStories(@Query("page") page: Int?): Deferred<Response<List<StoryResponse>>>

@EnvelopePayload("stories")
@GET("api/v2/stories/{ids}")
fun getStories(@Path("ids") ids: StoryIds): Deferred<Response<List<StoryResponse>>>

Got it working, so will open a PR for the other issue.