If I am not mistaken Akka HTTP has its own HTTP server layer that it uses
(when you do Http().bind(..)). You can find more details in the Core Server
API section of the docs. It discusses in some detail what's going on under
the hood and how Akka's HTTP layer is, in my view, essentially a
What does your application start up look like? Your description of the
actors as Crons makes it sound like they are created at application load
with scheduler instances initialized at that time so I'm personally not
sure what you're looking to "revive". Do these actors have some kind of
state?
Not quite sure what you mean when you say you don't want to "manually
encode" the routes in Akka HTTP. What is it about Akka HTTP that is giving
you trouble?
I personally have built a couple Akka applications with a REST API sitting
in front of it. Most of the time I've used http4s but I've
I've personally implemented something similar using CQRS. In Akka that
roughly translated to an Actor for reading data and an Actor for writing
data (using Futures to wrap the actual repository interaction). The actual
implementation had a bit more meat to it but the general idea was an Actor
I'll echo the answer Justin provided. I normally taken existing DB access
code and wrapped it in an Actor with Futures without issues. Was there any
specific use case outside of your typical DB interactions (such as trying
to take advantage of Event Sourcing)?
On Friday, May 13, 2016 at
Option 2 is what I normally use since you're taking advantage of what Akka
already has built in. I have a couple apps in prod that use this technique
and it works fine for our needs
On Friday, May 6, 2016 at 6:42:33 AM UTC-4, scala solist wrote:
>
> I'm started to work with akka as scala actors
I've had experience building with both. The more-recent Akka-HTTP version's
High Level API feels like a familiar friend if you came from Spray
applications:
http://doc.akka.io/docs/akka-stream-and-http-experimental/current/scala/http/routing-dsl/index.html
(as it should. It's basically the
