Hi, I have a simple use case where a service: - reads from a queue - uses that information to make a call to an external web service - caches those results to Redis so it doesn't need to make that external call every time - uses those results to send modified information to another queue
In the past we did it with Spring using synchronous requests for the external web service. We're getting more streamy now and there's a lot of interest in akka, which I've previously done some work with. So there's interest in rewriting this service in a reactive style. I've got a sample app that uses akka-streams to read from the queue, do an operation, and write back to another queue, and I can use akka-http to make the call to the service, but I'm stumped on how to appropriately cache. What's the best way in a case like this? The caching is simple - in the previous service it was just automatically caching a method call by its parameter values, via annotation. I've considered using scalacache since it has the familiar model of caching method calls by parameter. But I'm not sure it's really idiomatic for akka-streams (which I've just started using) or akka. Should I instead consider using akka persistent actors (one per service lookup I guess) or dumping Redis entirely and using akka distributed data? Thanks, Curt -- >>>>>>>>>> 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.
