Closely related (essentially a more scalable version of the same desire), something for folks to consider as a possible long-term idea:
I've been idly pondering for a few months what the interaction of Akka Streaming and Cluster Sharding *should* look like, in an ideal world -- what the end-user design would be. The specific (but fairly general) use case here is having an Akka HTTP front end working with Sharded Actors that are providing the guts of an application. I know that this can be done now, but it still feels rather clunky and homebrew, not as elegant as Akka Streaming itself. I believe what I *want* is to be able to define a Stage that is actually materialized as (roughly) a sharded, persistent Actor. As with normal Akka Streaming, the actual definition of the Stage wouldn't look much like a normal Actor definition, but I suspect it *would* look somewhat like a Typed Akka Actor declaration: strongly-typed, usually taking a Trait as its input type and actually processing subtypes of that Trait. It would be fundamentally stateful and Event-Sourced, although likely with the details of both the Sharding and the Persistence somewhat abstracted out. (Admittedly, there are probably limits to how far the Persistence can be abstracted, due to serialization considerations.) Key to all of this is that, when you add this Stage to a graph, what it actually materializes is a *proxy* that hooks into the normal Cluster Sharding system, wrapping the inputs in some sort of standard envelope build on top of the ID of this "stage". (As always for Sharding and Persistence, the stage would need to define what the ID is.) And in particular, it would be entirely legal (and normal) to have multiple Graphs talking to the same underlying Sharded Entity through these proxies. Each Graph would stick to its own knitting, logically speaking, but they'd all be talking to the same *data*. In principle, this seems to make a lot of sense -- after all, a well-designed Persistent Actor can be thought of as simply the sum of a stream of events. I *suspect* it would allow one to build Sharded/Persistent applications more elegantly, with significantly less boilerplate. (I also suspect it would obviate some use cases of Typed Akka, but I don't think that's a complete tragedy. If designed with some foresight, it might make the transition to Typed Akka easier for projects that adopt this.) All of this is rather hypothetical, of course -- I'm sure there are many challenges lurking under the surface, and I don't know the relevant code yet. But it's where I'm winding up when I ask, "what would it mean to use Akka HTTP in Querki?" I'm coming to strongly suspect that there's a relatively elegant and general abstraction lurking here, the Sharding/Persistence equivalent of Akka Streaming, and that it holds similar promise to drag more of Akka up the abstraction stack... On Mon, Feb 6, 2017 at 10:59 AM, Viktor Klang <[email protected]> wrote: > Would it be more flexible with a `persistentBuffer` stage? > > On Mon, Feb 6, 2017 at 4:54 PM, Konrad Malawski < > [email protected]> wrote: > >> Would you be up to implementing it? Otherwise I don't think there will be >> much happening around this. >> It could start out in github.com/akka/akka-stream-contrib >> >> -- >> Konrad `ktoso` Malawski >> Akka <http://akka.io> @ Lightbend <http://lightbend.com> >> >> On 6 February 2017 at 16:51:19, Héctor Veiga ([email protected]) wrote: >> >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c >> urrent/additional/faq.html >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> --- >> You received this message because you are subscribed to the Google Groups >> "Akka User List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Cheers, > √ > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/ > current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
