Play! info mix

Play! info mix

Play! links

• Node.js vs Play
• BigPipe using Play, RxJava, and Hystrix
• Many play usefull activators
• Ybrikmans Blog
• Play under hood
• Gilt and microservices with scala and play
• Play framework and LinkeidIn
• Play with linkedin
• [How is Akka used in Play!] (http://stackoverflow.com/questions/22718905/how-is-akka-used-in-play)
• Play Framework: async I/O without the thread pool and callback hell

Other links

• What is reactive programming
• Introduction to reactive programming
• Quick start with reactive programming
• rxjava-jdbc
• Performance of frameworks
• Concurrent Programming for Scalable Web Architectures
• Threaded vs. Evented
• [Why events are bad idea] (https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/index.html)

Some notes

• Deadbolt2 problems described with using JPA https://github.com/schaloner/deadbolt-2-java/blob/master/QuickStart.md

• when you see in terminal

Warning: node.js detection failed, sbt will use the Rhino based Trireme JavaScript engine instead to run JavaScript assets compilation, which in some cases may be orders of magnitude slower than using node.js.

... you need to install Nodejs (for example on Debians apt-get install nodejs). Reason is performance when play run javascript it can be much faster with Nodejs.

• ebean deprecated, use JPA instead. reasons : 1 , 2

• we didnt use Akka-HTTP in this project but rather standard Netty because see. Actually Akka-HTTP is written for typesafe by Spray creators. (Spray creators creates Akka-HTTP.

• [Reactive streams] (https://www.playframework.com/documentation/2.4.x/ReactiveStreamsIntegration) in Play! are highly experimental. There is no Java API for now ! (v 2.4)

• Future of Play! is Akka-HTTP with reactive streams.

• Non blocking in Play! is The Play WS API, Sending/receiving messages to/from Akka actors

• Play project structure has changed few times with new versions

• Twirl Play! use for view rendering Twirl templating. Is default but you can use others. Is non component based but you have helpers with dynamic html elements in it. Is compiled == type checking, your IDE can helps you like with java code. (type checking). Your views are just scala functions so you can call it. Type checking on compile time.

• Play! hooks

• By default is Play! intended work with short requests. If you have not, long request block the Akka component of Play! app. (Akka thread pool is saturating). It can be solved by execution contexts.

• Flash scope take 2 requests. Use flash scopes for redirects and rendering errors.

• Session scope for session uses Play! cokkies. That means that you have max. 4Kb memmory for session and your data are stored to client side in ecrypted form. Everything is Key, Value pair (Strings).

• SBT and Nexus

• Creating standalone version of Play! app

• Play! alternatives Spray, Xitrum

• Composition is very usefull and important behaviour or practice. Do complicated things like many easy and small stuffs. With Java Play! you can use composition. With Scala Play! is more easy do this because Java doesn’t support first class functions. Composition can be done with WS library but it is not so good because when you change your router you need to think about changing also WS calls urls.

• Promise<Result> over Result

• code in controller methods must be thread safe ! watch out !

• stateless == thread safe

• Threaded vs. Evented servers : threaded server gives for request thread from pool, when is done put thread back to pool. 1 thread per 1 request paradigm. Use blocking IO. Evented : have one thread/process per CPU core and uses non blocking IO. In a threaded server, threads spend most of time idle and waiting on I/O. And thats the point ! Play! uses evented server.