Background

Currently, each story category (top/best/jobs etc.) returns at most 500 entries. Sorting and filtering through those entries is quite fast. However, I want to be able to sort/filter through every single post since the beginning. In order to do so using hackernews APIs, I would need to retrieve every single item from id=${maxItem} to id=0. Having to do this every time a user wants to view posts sorted in descending order by the number of votes for example would be too inefficient and wasteful. Therefore, having a database for this will minimize the number of API calls that will be made.

A caching layer (redis) can also be used to cache the sorted/filtered items so that we don't have query the database constantly. The entries can be set to have a TTL=1hr

Tasks

• Set up a database (most likely an RDB) with the Tables/Documents modelled after the hackernews API models
• Seed the database with initial data (insert every item into the database from the current id=maxItem to id=0
• Set up redis as the caching layer between the database and the webapp
• Wire up the data retrieval, sorting and filtering functionality using a repository layer within the nextjs app, using an SQL query builder if possible instead of an ORM
• Update the UI for the additional functionality

Acceptance Criteria

• A user is able to view the highest rated posts of all time/last week/last month/last year etc. similar to reddit. The ranking will be based on the last updated value (retrieved from the redis cache or otherwise)
• A user is able to sort posts by votes/number of comments/date created in various time periods - all time/last week/last month etc.
• A user is able to view all posts by a certain user (possible with a RDB)
• A user is able to sort/filter posts within an arbitrary time frame. This operation can't really be cached in contrast with the "preset" time periods as mentioned above, so it will take a longer time to process

Additional notes

• AWS Elastic Cache can be considered as the redis solution
• PlanetScale can be considered as the RDB solution
• tRPC can be used to make the DB calls type-safe through Nextjs API routes

Background

Currently, hackernews-next uses a paginated model to display stories. This model works well but some users may want to have infinite scrolling instead. This would provide a smoother user experience and make the navigation of the site more intuitive.

Tasks:

• Look into useSWRInfinite to implement infinite scrolling
• Use query/path params to separate the paginated view and infinite scrolling view
• Test the infinite scrolling using playwright

Completion Criteria

• Given I'm on the infinite scrolling page view for the stories list
• And I scroll to the bottom of the page
• Then I should see a loading spinner at the bottom of the page, after which the next page of stories will be rendered. If there are no more stories, I should see an indicator/alert which tells me that there are no more stories.

Background

Currently, hackernews links within comments or posts will open in the original hackernews website (naturally). This might disrupt the user experience of hackernews-next if the user wants to continue browsing other hackernews items on the same website.

Tasks

• using the replace/transform option in react-html-parser, replace all <a> tags where the URI starts with news.ycombinator.com/item with a custom link component.
• set up the custom link component such that clicking it will trigger a popover, presenting the user with 2 choices - go to the original link or view the item in hackernews-next

Acceptance Criteria

• Upon clicking a link matching news.ycombinator.com/item in comments or posts, a popover will be triggered, allowing the user to choose between going to news.ycombinator.com/item or hn.oyxw.xyz/item