A Little Guide on Using Concurrent Futures for Web Developers

I imagine that Futures are something like JavaScript Promises. I just thought I should mention this because "Web Developers" was mentioned in the title, but the topic itself is Scala oriented. Nothing wrong with this, but it could mention Scala in the title.

Just want to add that as much as I dislike scala syntax, this future based workflow with the Play Framework is ridiculous fast. If you can factor your controllers and request most of the models in parallel things get really fast.

Does exists something similar in another language, with a good web framework? I really like the performance, but the syntax throws me off a bit.

I appreciate the article. I was confused by one part though. You talk about how to combine multiple Futures into a Future of a tuple and give two example on how to do this. One that will not execute the futures in parallel:

  // Returns Future[(User, Seq[Message], Seq[JobOffer])]
  // ** NOT EXECUTED IN PARALLEL **
  val result = for ( 
    user     <- userByEmail("stephan@ubercto.de");  // User
    messages <- newMessages;  // Seq[Messages]                         
    offers   <- newOffers   // Seq[JobOffer]                             
  ) yield {
    // do something here
    (user, messages, offers)
  }

and another that will:

  // Futures are created here
  val userF = userByEmail("stephan@ubercto.de"); 
  val messagesF = newMessages
  val offersF = newOffers

  // Returns Future[(User, Seq[Message], Seq[JobOffer])]
  // ** Executed in parallel **
  for (
       user     <- userF;
       messages <- messagesF;
       offers   <- offersF
       ) yield {
         (user, messages, offers)
  }

and I'm having a hard time seeing the essential difference between these two bits of code. How is it that creating the futures before the 'for' expression results in the Future of the tuple being executed in parallel? I'm thinking that the 'for' expression gets expanded to basically the same flatMap/map expression in both cases. And that each 'step' in this flatMap/map expression can only be evaluated after the previous 'step' has finished, so neither of these approaches will run in parallel.

Great little guide.

Now...my negative view on using Futures as per the examples in the guide:

Futures (and concurrency in general) make your code much harder to reason about, and much harder to debug. Sequential code running in one thread makes life much easier for the developer.

Faced with the problem presented in the guide (3 method calls total 400 ms), I'd try hard to optimise the methods. Once I've squeezed every potential performance gain out of the sequential method, I'd then investigate caching. Finally, if I still had significant performance problems would I then look at concurrency.

Author here, if you have anything to add, I'm glad to add it to make it a comprehensive guide on Futures.