Hacker News Reader

Comment by breatheoften | Hacker News Reader

At first glance -- async/await mitigates a lot of my least favorite things about orm dsl's -- namely that it can be difficult to tell when the orm framework is actually going to generate a db round trip without being familiar with the implementation ... thinking back to the most recent orm i had to learn (rails) and how it was quite annoying to get started with while interacting with an existing codebase. clear suspension marking would have made the code vastly easier to follow and allow making inferences about where things were happening even as a unfamiliar with the dsl ...

View on HN

This doesn’t always work with Node APIs, one example that comes to mind is fetch (for making URL requests). When you await a fetch(url) you get a response object, where a bunch of functions on it (like json() IIRC) are themselves promises - but not making another API call. I’m not actually sure why it’s structured like that, I guess to give unified error handling/callback syntax between the call failed and the unexpected response branches maybe? But it means that you can’t rely on await to delineate where round trips are happening at least in that case.

I think it’s because of the different actions you might want to take after the fetch.

1. Parse the data as json

2. Return it without parsing

3. Modify some other part of the response but never parse the body

4. Turn around and stream that body into another fetch without parsing it.

Etc. parsing it and loading a large response into memory may not always be desirable so it must be explicitly done with await res.body.json().

I agree that it might never be parsed/you might not want to, and that it shouldn’t be done implicitly. But I’m not sure why that requires await instead of just a plain function call to parse it explicitly.

Parsing JSON is synchronous, but fetch itself doesn’t read the body data.

> [1] to parse the body as JSON, first the body data has to be read from the incoming stream. And, since reading from the TCP stream is asynchronous, the .json() operation ends up asynchronous.

[1] https://stackoverflow.com/a/59555579

Is that basically the same point at a lower level though? I don't think reading the stream involves a round trip?

Reply on news.ycombinator.com