Choosing actor in akka http


when using akka http, how we should choose actor?
for example i have 6 api(6 route with many get-post methods): /user, /order, /admin, …
all 6 api should be actor( i think this is true)? or no actor?
i have worked on project that in rest part although it used actor system but
none of its apis were actor(project was successful)


The basic guideline is to use Actors only where it makes sense, that is where you have to deal with state. In many cases, it does not make sense to create actors just for route handling. Instead, handling a request will usually consist of calling methods that return a Future. In some cases, those methods will be implemented by using ask on already running actors. That’s absolutely fine and recommended, but creating an actor per request or per connection (as it used to be done with Spray a long time ago) is not necessary.


1 Like

thank you

(i know that something about stateless and stateful programming,akka is stateful programming and want to reduce calling db. am i right?)
state in most of the cases means db related things. so you mean
which api that need db action, should be actor?each api has several methods, maybe
one method need db but others don’t need it.

for example in small e-commerce site:
we have: /profile, /product, /order, /order-item, /payment, /admin
which api you choose as actor?

State in this case is about state in memory of the JVM application, for example to not have to go to the database for each interaction but instead respond from memory, and that way being able to respond faster, using less resources.

If all you want to do is parse a HTTP request, trigger a database query, and turn the response into a HTTP response - all state is in the database - there is no need to use actors.

Compare this to for example a chat room where different HTTP clients talk to each other via the server (via websockets perhaps) - it might be better if that chat room keeping track of clients was only in the memory of the server (depending on the requirements on the chat of course - does it need to survive a server restart for example) than if they repeatedly had to poll a database for new messages.

1 Like

thank you but

i think this is not good way that if we have db connection we should not use actor.

Not entirely sure I understand that last reply correctly, but:

What you base the decision on should not be about whether you have a database or not but if your application can benefit from keeping state in the memory of the JVM.

In many cases a completely stateless CRUD-application is fine, and for that doing async with Futures is fine, at some point you may realise you want to keep some state in memory and at that point you can introduce actors even if you didn’t design with them from the beginning. It’s not an either-or situation, it is fine to mix actors where they are needed with futures where those fit better.

1 Like