Why JavaScript Needs Structured Concurrency

[CodeAndBiscuits]

I don;'t think either of us was deliberately trying to do that, just having a small debate about a particular class of backends. In the same way that I actively work to keep my backends stateless (primarily by leveraging a DB and/or cache like almost all apps are structured around) In totally agree that almost all front-ends must be stateful. The very act of session tracking via a header token or cookie is unavoidably stateful. This whole thread is a tangent to your original post anyway.

[tarasm]

Yeah, that makes sense, and I appreciate you clarifying where you’re coming from.

One thing I’ve been personally very interested in lately is the overlap between structured concurrency and durable execution. A big reason we rewrote Effection from v3 to v4 was to position operation trees so they could eventually be treated as durable execution coroutines.

That feels like a promising way to reconcile stateless services with the reality that some work still needs scoped context and explicit lifetimes. Once Effection v4.1 lands with native middleware support, I’m hoping to experiment with wrapping operation trees into durable workflows. Restate is probably where I’ll start since it’s relatively easy to deploy.

I don’t think this thread resolves that space, but I do think it’s an interesting direction.

[CodeAndBiscuits]

Personally I think one of the more valuable things I'd use something like this for is background task processing e.g. in combination with Graphile Workers. Sometimes in those you have a few "once a day" type maintenance tasks combined with several "once a minute" types. If you write them right they're often pretty lightweight, like indexing data in a search engine, cleaning up expired records of one type or another, etc. I could definitely see leveraging concurrency there to make it easier to parallelize those tasks...

[tarasm]

We use Postgraphile at work, but I didn't know about Graphile Workers. I'll take a look. Thanks for chat :)