> Half these issues stem from a relative misunderstanding of exactly where the code is running.

If I take a look at other languages, these kind of multi-threading issues are usually represented by providing a separate context or sync package (that handle mutexes and atomics) in the stdlib.

And I guess that's what's completely missing in nodejs and browser-side JS environments: An stdlib that allows to not fall into these traps, and which is kind of enforced for a better quality of downstream packages and libraries.

▲

christophilus 5 days ago | parent | next [-]

This has nothing to do with multithreading, though?

▲

arnorhs 5 days ago | parent | next [-]

Absolutely correct. Those are runtime execution context-issues. There are other frameworks that do force you do deal with those (and in other languages, probably), but I believe in next.js the difficulies are at another level - because of poor documentation and the built in abstractions to allow for running next.js both in development, node.js server, and edge.

▲

cookiengineer 5 days ago | parent | prev [-]

Not OP but wasn't the article about lots of async/await context issues?

If the handle() method of the middleware API would have provided, say, a context.Context parameter, most of the described debugging issues would have been gone, no?

	▲	h4ck_th3_pl4n3t 4 days ago \| parent [-]
		Yes, that's what I meant

▲

5 days ago | parent | prev [-]

[deleted]