In the project I am working on, I am using the MVP architecture. In Presenter classes network requests are executed with RxJava2. Is it OK to use Kotlin Coroutines as well?
Yes.
For example, you might want to use coroutines for light-weight async tasks, while using RxJava for getting a stream of items and transforming the stream into another one using complex operations. They are just two different tools and approaches to asynchronous programming.
Related
I want to use AWS SQS in my Play 2.4 project.
There are two options at moment:
There is a SQS wrapper called https://github.com/kifi/franz which supports reactive way of using that. But it seems not quite popular on Github not sure how mature it is? Whether the developers will continue to maintain it.
There is Java SQS SDK, but it doesn't support Scala Future (reactive way). If I want to make it non-blocking, could I use Akka or?
I haven't used SQS yet but I did have a similar need for DynamoDB. I tried using a third party Scala specific library -- bad idea (buggy, bad api, missing features). In the end I wrapped the AWS Java SDK. Making it 'reactive' is pretty easy and is similar to most things you would do in Scala. Call the AWS functions within a Future body (Future {}) and use functional constructs to process the result (map, reduce etc..).
I'm transitioning from Java to Scala, and started using Play as application server. My Java legacy application (the one I'm trying to replace) is built on three layers: servlets, session beans and entity beans. I read that Akka actors would replace session beans, is that accurate? When is it appropriate to use Akka actors in a Play web application?
I don't think there is any thumb rule like convert Session Beans / Entity Beans to actors.
You may need to look at your requirements. It's worth considering what the actor model is used for: the actor model is
a concurrency model that avoids concurrent access to mutable state
using asynchronous communications mechanisms to provide concurrency
This is valuable because using shared state from multiple threads gets really hard, especially when there are relationships among different components of the shared state that must be kept synchronized.
However, if you have domain components in which:
You don't allow concurrency, OR
You don't allow mutable state (as in functional programming), OR
You must rely on some synchronous communications mechanism,
then the actor model will not provide much (if any) benefit.
Take a look at this URL if you haven't already http://www.infoq.com/news/2014/02/akka-ejbs-concurrency
To answer the second part of the question:
When is it appropriate to use Akka actors in a Play web application?
Scala is not just syntactical sugared Java but meant to write Functional Programming(FP). Scala makes writing functional code easier and more obvious. When you do this all your methods become functions(no state change is held).
From here when you do want to hold global state, you encapsulate it within an Actor and interact with it only via a messaging queue.. and therefore don't have to concern yourself with threading logic.
A great course to get started with this is https://www.coursera.org/course/progfun
A great book to get started with Scala is:
Scala for the Impatient by Cay S. Horstmann
I'm searching some library which implement the Component Based Entity System (ECS) framework used in multiple game and implementend in many game engine (unity, libgdx, etc.)
I'm starting a little game project in scala ( ECS roguelike), and at this time i only find a java library named ashley.
Do you know if other ECS libraries (in Scala) exists, or if the only way is to use or reimplement this library in scala (ashley) ?
Another related question, the Actor paradigm and Component Based Entity System is not so distant, what is the difference ?
Regarding the question about differences with an Actor system, the purpose of an Actor system is to allow asynchronous communication between actors. i don't see anything in ECS which is related to asynchronicity. In fact, from one of your links:
Each system will be updated once per frame in a logical order
This implies synchronous, blocking progress through the program, so quite different from an actor system where the components would be sending each other messages in a concurrent fashion.
Regarding your need for an ECS library in Scala. Scala and Java are interoperable, is there any reason you can't simply use ashley within your scala code?
In our Scala/Play application we use activiti. (also experimenting with camunda) users can create workflows (shown in this picture http://camunda.com/ ). All calls to these external workflow engines are wrapped in Scala Future (activiti and camunda APIs are all Java blocking APIs).
is there any library to implement workflows totally using Akka/Actors avoiding heavy toolkits like activiti/camunda? Or ideas how to best use Akka with activiti/camunda ?
You could try and use the Akka FSM dsl to do the same bypassing activity and also blocking apis. see http://doc.akka.io/docs/akka/snapshot/scala/fsm.html
Note that camunda has very powerful asynchronous continuation features which allow you to delegate any long-running processing to background threads. This allows very flexible configuration of "how much work" is done synchronously in the client (possibly HTTP) thread. This can give you a good balance between performance and fault tolerance.
I know of the existence of the Catify BPMN Engine, built using Akka (Java). I do not have any experience with it, nor do I know for sure whether API calls are asynchronous, but I would expect so. Since it is written in Akka it should combine well with Play!.
Is SignalR the same thing is Reactive Extensions? Can you explain why or why not?
No, they are absolutely not the same thing.
Reactive Extensions is a library for creating and composing observable streams of data or events (which are actually quite similar). It basically knows nothing about client-server connections or other things. It is focused solely on Observables and is capable of wrapping any collection, stream, event, async method, etc. into the common Observable interface.
SignalR is a toolkit for creating persistent (i.e. alive) duplex connections between client and server. It works over HTTP and its purpose is wrapping 3 low-level techniques: long-polling, server-side events and web sockets into a high-level API for comfortable development. So, it's focused on the communication.
So, the components themselves are quite independent from each other, and they have completely different concerns.
On the other hand, these 2 great libraries are complementary to each other: one might use SignalR to push events from server to clients and then wrap the server-side events into RX's Observables to create complex reactive user experiences.
UPDATE
Rx is like LINQ, it helps you specify 'what happens', it doesn't get into the details of 'how'. SignalR is a library to implement the 'how' for real-time network communication – Paul Betts
The difference between 'LINQ to Objects' and RX is that in 'LINQ to Objects' you pull next items from an enumerable thing, while in RX they are pushed to you from an observable thing.