Fast and maintainable patterns for fetching from a database

sophiebits.com

9 pointspspeter34 comments

Am I missing something or wouldn't this be much (much) more efficient to do in SQL with a single parameterized query?

If you are, so am I.

From the description "like to render a summary of published posts, with the post title, author, number of times it’s been viewed, and a fun fact about that view count number" I don't even see why you'd need a parameter.

Just gotta rethink the architecture so that it scales: this sounds like at least 3 separate APIs w/ at least 3 separate DBs should be stood up. This is of course because if the post-title service goes down then the customers can still access post-authors and post-data from their respective services.

/sarcasm

Yeah... I dunno what this article is trying to teach me from a database interactions perspective. It's unclear whether the JavaScript is executing client side or server side. The final code block seems like a really inefficient implementation if not constrained to some existing API.

I think this may be better refactored as a post about async / await and Promise.all().

Reply on news.ycombinator.com