A Simple Example of WebSocket based Microservice Architecure using Akka-HTTP in Scala

Knoldus Blogs

In my previous blog, I explained how you can implement WebSocket server using Akka-HTTP. As you know,  Microservice architecture has become very popular in recent years. This architecture fits perfect
1) When you want to give support of your application for many platforms such as web, mobile etc.
2) When your application consists of multiple services such as order service, account service, payment service etc.

In this blog, I have explained a simple example of WebSocket based Microservice Architecure using Akka-HTTP in Scala. You will see how WebSocket based Microservices can communicate with each other in a application.


In this example, there are two sub modules Account for Account related services and Order for Order related services. There is one more sub module Api, which will forward coming requests to their corresponding services.

Let’s create build.sbt for this multi module project.

Screenshot from 2016-08-08 00-48-08.png

Now create routes and its handler for Account…

View original post 79 more words

Akka HTTP vs Other REST API Tools

Knoldus Blogs

Hi Folks !

Lately there have been a lot of tools that allow us to build rest APIs like the following :

  • Akka Http
  • Play
  • Scalatra
  • http4s
  • Finch
  • Spray

In my blog today, I will be discussing Akka Http and its counterparts(competitors) in terms of their advantages, disadvantages, performance and use cases.

Let us begin comparsion of Akka-Http with Scalatra.

Scalatra is a thread based,it works by handling servlets and requires servlet container like jetty to run, it can delegate work to akka as per its documentation.On the other hand akka-http is actor per request, and it doesn’t require a container and writing actor model code is more natural pattern. In terms of DSL, Both have comparably easy and well written DSLs for writing routes.

Comparing in terms of performance it has been noted and well established in practise that akka-http application behaves much better than scalatra and continue to…

View original post 567 more words

Blending Cucumber, Cassandra and Akka-Http

Knoldus Blogs


Knoldus has always pioneered the deep diving into the best ways to use cutting edge technologies. In the past few days, one of our team carried this deed by integrating Cucumber with Akka-Http, Cassandra and of course, Scala. In this blog, we reach out to you to explain and show how this can be done.


Cucumber is for Behavior Driven Design (BDD). The approach of Cucumber is to write the behavior of the application and then run them for acceptance testing.


Akka-Http is a general toolkit provided by Akka to implement HTTP services. It supports both client and server side services.


Cassandra is a database that provides high scalability and availability with best performance.

View original post 197 more words

Building Apache Spark with Scala 2.10

As we know, Spark is a Map-Reduce like cluster computing framework, designed to make data analytics fast.

In the official website of Spark, latest release is Spark 0.7.3. But this release requires Scala 2.9.3. If you are using Scala 2.10, this release would not work.

Since Spark has not announced any Scala 2.10 compatible release yet, so to build Spark with Scala 2.10, you have to download latest release from here: Spark-Scala 2.10.

Installation instructions would be the same as previous release.

Since Spark Api for this release is not available on any repository, so if you want to use it in your project, you need to do:

1) Go to Spark directory

2) Run sbt compile publish-local

3) Add
libraryDependencies += "org.spark-project" %% "spark-core" % "0.8.0-SNAPSHOT"
in the build.sbt of your Scala project.

Bridging the Communication between Lift Comet Actor and Akka Actor in Scala

In this blog, I would explain how to create bridge between Lift Comet Actor and Akka Actor.
Since Lift has its own actor model, so a bridge is needed to fill communication gap between LiftComet and Akka Actor, so that Akka actor would be able send message to comet, once comet has been set.

This bridging concept would be more useful for those web applications, which are built in Lift and using Akka Actor for message passing and running in distributed environment.

I have created a small Lift Login application with Things to Do and Chat functionality. you can find full source code here on GitHub:

You will find bridge concept in Chat Module.

class BridgeActor extends Actor {
  private var target: Option[CometActor] = None
  def receive = {
    case comet: CometActor => target = Some(comet)
    case msg => target.foreach(_ ! msg)

 * Controls the life-cycle of Actor Bridges
object BridgeController extends Loggable {

  def getBridgeActor: ActorRef = {

Here is one BridgeController, which would provide a BridgeActor on the request of Chat comet. Comet would get registered in forwarding target.
Akka actor would send message to this forwarding target.

Concept would be more clear from below lines:-

In Chat.scala:-

/*Requesting Bridge Controller to provide BridgeActor*/
private lazy val bridge: ActorRef = BridgeController.getBridgeActor

  override def localSetup {
    bridge ! this
    val future = akka.pattern.ask(alertManager, Subscribe(bridge, User.currentUser.open_!.id.is))
    val result = Await.result(future, timeout.duration).asInstanceOf[List[(ObjectId, String)]]
    chats = result

 override def localShutdown {
    alertManager ! Unsubscribe(bridge)
    bridge ! akka.actor.PoisonPill

We need to instantiate bridge at the time of setting up comet. This would register comet in forwarding target of BridgeActor.
We also need to kill bridge actor at the time of shutting down Comet. We can do this by giving PoisonPill.

This is a working example and would be more useful for remote application.

Please provide your valuable feedback.

A Simple Remote Chat application using Lift Comet and Akka Actor in Scala

If you are running an application and there are lot of chances for a huge traffic to come in future, a single server would not be capable to handle this.
In that case you would have two choices:
A) Replace existing server with an advance server with better configuration
B) Building a global node in the cluster to be used by other nodes.

We know that first option is not a permanent solution. So lets move to second option.

I have created a Login Application with Things To Do functionality using Lift in Scala.
In this application, I have added a chat module using LiftComet Actor and AkkaActor.

In the Chat Module, I have implemented cluster functionality, so that application could be accessed remotely.
So the concept is: there would be one Akka Actor on central server and this central akka actor would be used by other comet actors, whether they are on the same server or different server.

Since Lift has its own actor model, so I have created a bridge between LiftComet and Akka Actor, so that Akka actor would be able send message to comet, once comet has been set.

To learn bridging concept in deep, go here : http://riteofcoding.blogspot.in/2011/05/beyond-chat-lift-comet-and-akka.html

In this application, there is one controller

object CometAlertController extends Loggable {

This controller would give central actor reference, if exists, otherwise create a new central actor, if not exist. Here I have created a central actor with hard-coded configuration,
You can change this according to your application.

  private def getOrCreateActor: ActorRef = {
    try {
      val actorRef = GlobalActorSystem.getActorSystem.actorFor("akka://Node@" + hostAddress + ":3557" + "/user/Manager")
      val future = akka.pattern.ask(actorRef, Ping())
      // Use Await.result, if blocking is necessary
      // Use mapTo for non-blocking scenario
      val result = Await.result(future, timeout.duration).asInstanceOf[Ping]
    } catch {
      case e: TimeoutException =>

As you can see in the above method, first controller will ping to central actor by sending a Ping message.
If actor exists, it would send a reply otherwise a TimeoutException would be thrown. If TimeoutException is caught in catch block, controller would create a new central actor.

  private def createActor = {
    val remoteSystem = ActorSystem("Node", ConfigFactory.load(configuration))
    val result = remoteSystem.actorOf(Props[AkkaAlertActor], "Manager")

  def getManager: ActorRef = getOrCreateActor

There is GlobalActorSystem.scala to create single actor system throughout the application.

For the chat module, there is Chat.scala, which is comet actor and AkkaAlertActor is Akka Actor.
The comet actor and akka actor would communicate with each other using BridgeActor, which works as a bridge between comet and akka.

Since In a remote application, actors would pass message throughout the network, so those messages must be serialized. To serialized those messages, I have implemented Akka-Kryo-Serialization.

How to run application:-

A) Clone code from https://github.com/romix/akka-kryo-serialization.

B) Run sbt compile publish-local

C) Now clone https://github.com/knoldus/Lift_UserLogin_Template

D) Run sbt ~container:start

How to test in remote environment:

A) Open a terminal and run sbt ~container:start.

B) Open build.sbt and change

port in container.Configuration := 8081

C) Open another terminal and run sbt ~container:start.

D) Register yourself and login and Enjoy chat.

You would be able to do chat remotely. Check and let me know your feedback. Your feedback would be highly appreciated.