Yana P

[YanaP1312]

Completed Week 6 assignment: database connection, web fetching, and interface testing.

• Implemented user statistics endpoint with SQL‑computed fields and 404 handling
• Implemented track lyrics endpoint using Spring RestClient with proper error responses
• Added MockMvc integration tests:
  • 2 tests for user statistics (happy path + 404)
  • 3 tests for track lyrics (happy path + missing track + missing lyrics)
• Configured PostgreSQL connection and loaded Postify schema/data
• Organized package structure for controllers, services, client, dto, exceptions, repository and tests

[composix]

Very solid implementation that feels production-ready. The coding patterns are consistent, and the code is kept simple and easy to read. I also like the minimal use of external libraries and the consistent use of Java records for DTOs.

Nice creative thinking as well: instead of trying to be a “database wizard”, the solution focuses on delivering a clear, maintainable, and reliable application.

[composix]

Nicely configured RestClient. Static request information, such as the base URL and default Accept header, is centralized in the configuration instead of being repeated across individual requests. This keeps the client code cleaner and easier to maintain.

[composix]

Nice idea to wrap the external REST API calls in a dedicated service. This keeps the integration logic isolated and makes the code easier to maintain and test.

[composix]

Returning null here should be clearly documented, but using Optional would make the absence of a result more explicit and easier for callers to handle safely.

[YanaP1312]

Good point, thank you! Changed getLyrics() to return Optional instead of null — makes the absence of a result explicit in the signature and safer for callers to handle.

[composix]

If Optional were used in the LyricsClient, this code could be made more consistent with the findTrackWithArtist call. The caller could then use orElseThrow, making the “not found” flow more explicit and avoiding a separate null check.

[YanaP1312]

Done — TrackLyricsService now uses .filter(...).orElseThrow(...) on the Optional returned by LyricsClient. Much cleaner than the manual null check, thanks for pointing this out!

[composix]

This is a useful startup check to verify that the application can connect to the database when it becomes ready. Consider using a logger instead of System.out.println, and make sure this class is registered as a Spring bean, for example with @Component.

[YanaP1312]

Fixed both — added @component so the class is actually picked up by Spring (turns out @eventlistener was silently never firing without it), and swapped System.out.println for a proper SLF4J logger. Good catch on the missing bean registration!

[composix]

I like the initiative to not force everything into one large SQL query, even though the exercise mentions that as an option for SQL wizards. Splitting the logic into smaller SQL queries and Java methods can make the solution easier to read, understand, and debug.

[YanaP1312]

Thanks! Splitting it into separate queries just felt more logical to me — easier to read, easier to debug later, and you don't need to hold the whole schema in your head to follow it. Though I'd love to get comfortable enough to fit it all into one query eventually!

[YanaP1312]

@composix, thank you so much for such a thorough and thoughtful review — really appreciate the time you put into going through the whole PR in detail! Learned a lot from this round, especially about being explicit with Optional instead of relying on undocumented nulls.