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

Improve API of Streams #679

Open
calvinlfer opened this issue Sep 23, 2024 · 5 comments
Open

Improve API of Streams #679

calvinlfer opened this issue Sep 23, 2024 · 5 comments

Comments

@calvinlfer
Copy link
Contributor

calvinlfer commented Sep 23, 2024

The current API of streams is quite sparse/low-level requiring the user of the API to drop down to the underlying representation of Emit in order to deal with complexity (if you take a look at Virgil Kyo to see me struggling 😂). The underlying representation feels akin to ZIO’s channel or FS2’s Pull but it would be much nicer to offer more higher level combinators that prevent/delay the user of the API to reach for lower levels immediately and allows one to stay at a very high level of abstraction until one cannot and requires fine grained control and performance. The idea at least naively would be to eventually replicate the API surface (or provide similar or better expressivity) of the other 2 streaming libraries.

Copy link

algora-pbc bot commented Oct 30, 2024

💎 $500 bounty • Kaizen Solutions

Steps to solve:

  1. Start working: Comment /attempt #679 with your implementation plan
  2. Submit work: Create a pull request including /claim #679 in the PR body to claim the bounty
  3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to getkyo/kyo!

Add a bountyShare on socials

Attempt Started (GMT+0) Solution
🟢 @maujim Oct 31, 2024, 3:40:04 PM WIP
🟢 @hearnadam Nov 18, 2024, 5:35:27 AM WIP

@maujim
Copy link

maujim commented Oct 31, 2024

Can you please clarify what the acceptance criteria are? I would like to /attempt #679

@hearnadam
Copy link
Collaborator

hearnadam commented Nov 18, 2024

/attempt #679

Algora profile Completed bounties Tech Active attempts Options
@hearnadam 4 getkyo bounties
Scala, Shell,
Rust
Cancel attempt

@calvinlfer
Copy link
Contributor Author

Given my experience of having used FS2 Streams & ZIO Streams which are pull-based solutions. I would love to see the following, @hearnadam & @fwbrasil please feel free to add or subtract since you folks have way more expertise:

  • The ability to evaluate multiple effects in parallel (mapZIOPar and mapAsync/parEvalMap) preserving order
  • The ability to evaluate multiple effects in parallel (mapZIOParUnordered and mapAsync/parEvalMapUnordered) without preserving order
  • The ability to perform rechunking on the stream elements
  • The ability to group multiple elements together using time and space (groupedWithin(x.seconds, y.sizeOfChunk))
  • The ability to merge multiple Streams together (not sure if this makes sense)
  • An API like Pull/ZChannel to model Streams - we may already have this
  • The ability to have different ways to evaluate streams (runDrain/runCollect/etc.)
  • More high level operators to create Streams - like paginate/ZStreams.async
  • Integration with the rest of the Kyo ecosystem (Queue/Channel/etc.)

@DamianReeves
Copy link

I'd suggest adding a merge operation as well.

hearnadam added a commit that referenced this issue Nov 20, 2024
- stop using class member, enforcing accidental eagerness
- add new method: Stream.range to simplify creation of streams
- init/range: accept `chunkSize` to limit size of Chunks- Chunk.from
(Array): remove AnyRef type bound

The first PR to address #679. This change is important to ensure the
laziness of streams initialized from non-effectful sources.
hearnadam added a commit that referenced this issue Nov 23, 2024
PR 2 for #679 

Rechunk was a bit tricky to implement as the remaining 'buffer' would
get dropped unless the chunks perfectly aligned with the number of
emits. Because of this, it's necessary to Emit a final empty chunk to
ensure the buffer is flushed. This can sometimes drop the number of
elements in a given chunk if a user Emits an empty chunk, but that
shouldn't be a problem.

---------

Co-authored-by: Flavio Brasil <fwbrasil@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants