Question about best architecture for request/response using Akka

[Markus Jais]

Hello,

I have a question to make sure I choose the right architecture for my Akka application.

It is a service with a REST API (using Spray 1.1), gets a call from a Ruby client via HTTP (over which I have absolutely no control)

and has a few use cases including registering a user.

The registration has the following steps.

- 1) receive REST call

- 2) call MySQL DB to see if username already exists

- 3) process (reformat) and validate user data (calls external validation service via socket), enhance it with some values

- 4) filter user data and only use those who have certain properties like a minimum age or live in a defined range of countries 

   (all those requirements change and are saved in a config file which is loaded every 15 minutes)

- 5) save user in MySQL

- 6) send email to user for confirmation

- 7) reply with OK/200 or HTTP error code to the client who called the REST API.

Some of those steps may asynchronously call additional services in the future, some in a "fire and forget" manner, others where the response is important.

I thought about using Actors for all the steps using a pipe/filter architecture to change the user data in each step before saving it and sending the confirmation email.

In the end I want to let the caller know if everything was ok. (Client requirements I have to fulfill, cannot change them).

I want to do everything non-blocking. 

I think the "pipe" akka pattern might be a good way to solve this using futures to call the actors.

My questions:

- How do I let the first actor who receives the REST call  know that everything was ok so it can return OK/200?.

- Should I not use actors at all and just use futures? I would love to use the supervisor, maybe remote actors, etc, so not using actors might not be a good idea.

- Are there any sample applications that implement such a workflow?

Maybe I am just not seeing the big picture and this is all much easier than I thought but I want to ask before I go down the wrong road.

I use Scala 2.10, Akka 2.1 and JDK 7 for this application.

cheers,

Markus

[Patrik Nordwall]

Hi Markus,

On Fri, Jan 4, 2013 at 2:17 PM, Markus Jais <marku...@yahoo.de> wrote:

Hello,

I have a question to make sure I choose the right architecture for my Akka application.

It is a service with a REST API (using Spray 1.1), gets a call from a Ruby client via HTTP (over which I have absolutely no control)

and has a few use cases including registering a user.

The registration has the following steps.

- 1) receive REST call

- 2) call MySQL DB to see if username already exists

- 3) process (reformat) and validate user data (calls external validation service via socket), enhance it with some values

- 4) filter user data and only use those who have certain properties like a minimum age or live in a defined range of countries 

   (all those requirements change and are saved in a config file which is loaded every 15 minutes)

- 5) save user in MySQL

- 6) send email to user for confirmation

- 7) reply with OK/200 or HTTP error code to the client who called the REST API.

Some of those steps may asynchronously call additional services in the future, some in a "fire and forget" manner, others where the response is important.

I thought about using Actors for all the steps using a pipe/filter architecture to change the user data in each step before saving it and sending the confirmation email.

In the end I want to let the caller know if everything was ok. (Client requirements I have to fulfill, cannot change them).

I want to do everything non-blocking. 

I think the "pipe" akka pattern might be a good way to solve this using futures to call the actors.

My questions:

- How do I let the first actor who receives the REST call  know that everything was ok so it can return OK/200?.

One nice way of doing this is to spawn a new actor that that collects the result(s). This actor can be passed down the chain as sender or as explicit ActorRef in the messages. In this way you can use ordinary tell (no ask and pipe needed for the reply).

Use setReceiveTimeout to cleanup in case of backend failure/timeout.

 

- Should I not use actors at all and just use futures? I would love to use the supervisor, maybe remote actors, etc, so not using actors might not be a good idea.

If you have the (potential) need for remoting and supervisor based error handling it's a good idea to use actors.

Cheers,

Patrik

 

- Are there any sample applications that implement such a workflow?

Maybe I am just not seeing the big picture and this is all much easier than I thought but I want to ask before I go down the wrong road.

I use Scala 2.10, Akka 2.1 and JDK 7 for this application.

cheers,

Markus

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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 post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user?hl=en.
 
 

--

Patrik Nordwall
Typesafe -  The software stack for applications that scale
Twitter: @patriknw

[Markus Jais]

Hi Patrik,

thanks. Very helpful. I tried your approach and it works great!

Cheers,

Markus

---

Von: Patrik Nordwall <patrik....@gmail.com>
An: "akka...@googlegroups.com" <akka...@googlegroups.com>
Gesendet: 10:49 Montag, 7.Januar 2013
Betreff: Re: [akka-user] Question about best architecture for request/response using Akka

[Patrik Nordwall]

I'm glad to hear that. happy hAkking!

/Patrik