I'm diving into API design and facing some challenges as I build real-world projects. Right now, I have a straightforward CRUD API with Posts and Comments. Here are my main issues:
1. I want to create a gallery view with around 12 posts per page (using scroll pagination), where each post displays only the first 3 comments. However, I found that my ORM fetches all comments tied to each post, forcing me to use native SQL (like lateral joins) just to limit to 3 comments.
2. I also want to include some statistics for each post, such as the total number of comments and whether a moderator has commented. This complicates the SQL query significantly, and performance starts dipping as I add more statistics.
Caching doesn't seem effective either since any changes to comments (like additions or deletions) would require purging the cache for the entire page of posts. I'm curious about how this scenario is managed in real applications where associated collections (comments) and aggregated statistics are involved.
1 Answer
When you're designing your REST API, it's best to keep your endpoints separate. Generally, you’d have a `/posts` and a `/comments` endpoint, where `/comments` could take a `postId` query parameter along with pagination options. Instead of trying to pull everything in one query, hit the posts first, then query the comments separately. This is in line with classic REST principles. If you need to display metadata for your posts, consider adding additional fields to the post table or querying comments separately.
Some REST APIs include a single call for both posts and their data through nested objects, but for your use case, that might complicate things unnecessarily.
I get what you mean about wanting to avoid slow load times. But if you're implementing a small app, having multiple API calls (like one for posts and another for comments) shouldn't be a dealbreaker, right? Just prepare for potential performance expectations during job interviews.