Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Async capability combinators #179

Merged
merged 15 commits into from
Jan 24, 2024
Merged

Async capability combinators #179

merged 15 commits into from
Jan 24, 2024

Conversation

charypar
Copy link
Member

@charypar charypar commented Jan 23, 2024

This PR is work in progress on #91.

It turns out, surprisingly, that async capability combinators were always possible in "user land", and could be implemented as an additional capability, but the implementation is not exactly obvious, and this type of use needs to be supported by the capabilities being orchestrated across, especially crux_http.

This PR aims to make the use of async across multiple capabilities more obvious. There are a few challenges to overcome

  • The Orchestrate capability should probably come with crux_core
  • Automatically derive Clone for capabilities and the Capabilities struct, to avoid various lifetime errors when moving the capabilities or the context into the async blocks - decided against, it would conflict with custom Clone implementations
  • Provide a Never operation type
  • Avoid producing an Effect variant for capabilities who's operations are Never () fields are #[effect(skip)]
  • The use needs thorough documentation and an example
  • Existing capabilities need to expose an async version of their APIs (Implement async API in crux_http #180, Implement async API in crux_time #181, Implement async API in crux_kv #182)

All feedback on the ergonomics of this is welcome at this stage, but I'd like to aim to ship this soon, ideally this week.

@wasnotrice
Copy link
Contributor

@charypar thanks for this, it looks great! I'm so excited to try this in my app. I think it will help a lot with maintainability. I have some places where the flow of orchestrated events is really hard to follow.

In the example, there are two concurrent events, but it could easily be two sequential events, or any other orchestration, right?

@charypar
Copy link
Member Author

charypar commented Jan 23, 2024

@wasnotrice Yea, absolutely, it's just an open ended async context with access to the capability runtime, I'm pretty sure it can orchestrate an arbitrary graph of dependent effects (and emit events along the way).

One thing to be aware off is that it is likely to be quite hard to test "sub-steps" in isolation on long effect chains. The entire outer future is one atomic flow which can only be entered into at the top.

crux_macros/src/effect.rs Outdated Show resolved Hide resolved
@charypar charypar changed the title RFC: Async capability combinators Async capability combinators Jan 24, 2024
Copy link
Member

@StuartHarris StuartHarris left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yay!

@charypar charypar merged commit e5ce45d into master Jan 24, 2024
9 checks passed
@charypar charypar deleted the capability-orchestration branch January 24, 2024 17:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants