Reactive Play

综合编程 2015-01-27

TL;DR:Play applications are not automagically performant. I’m writing a book that shows how to use Play correctly, especially when used to working with threaded web-servers such as Tomcat or Jetty . Save 50% with the code mlbernhardt .

My book Reactive Web Applications with Play was launched through the Manning Early Access Program yesterday.

When you start writing a book, everyone you talk to roughly falls in two categories: people who haven’t written a book, and people who have. In my experience, people who haven’t written a book, upon hearing from you that you are starting to write a book, will cheerfully support you, saying things like “Oh this is great!” or “Wow, what is it about?”. People who have written a book (we will refer to people as authors in what follows, because that’s a bit shorter to write) will give you a look that combines pitty, pain (as if they were feeling pain from an old war wound, except that they haven’t been to war, at least not a real war, or at least not most of them) and a je ne sais quoi of “oh my god man you’re in trouble”. Now it would be a bit unfair to say that all authors react that way, and I only met a handful authors in my life who were not authors of technical books, and that was before I even remotely considered writing a book, so chances are that this behaviour is not common to all authors. After having given you “the look”, most technical authors then proceed to warn you that this undertaking takes a lot of effort. Some even may try to save you from yourself and try to convince you that you absolutely should not write the book. And when they realize that you’re a lost cause, they will give you a mild, gentle smile and wish you good luck.

Ok, it’s not that bad. I actually got very good advice from talking with other authors, and perhaps the

slight lack of enthusiasm

healthy skepticism on the part of authors is a good thing, in the sense that if you still really want to write a book after talking to a few other authors, then you have the strength of mind that is required for writing a book. Because one thing is for sure: your book is not going to be writing itself. Technical books even less so, because next to writing, you will also need to draw a bit.

Writing a technical book gives you awesome drawing skills

I think that a dangerous thing to do is to write a (technical) book for the wrong reasons. And it should be about something that you really care about and could spend hours talking about, boring everyone else around you to death, unless you’re at a technical conference, where it is acceptable to talk in length about one little detail and everyone is going to be just as excited as you are about that nice little optimization you just discovered the other day (I mean, we have to admit that we’re a weird bunch of people sometimes, at least to non-tech people).

I’ve been involved in the Play community for some years now, having written a few applications both in Play 1 and Play 2, including Play 1 Scala and even ported a large application from Play 1 to Play 2 (including porting the Play 1 template engine to Play 2 out of necessity). Lately I haven’t had time to contribute much in code anymore, which led me to think about other ways to do something related to Play, and eventually to contacting Manning about the Reactive Web Applications with Play idea.

The book covers some of the very important points which even though mentioned in the Play documentation don’t quite resonate with most of its readers. Sometimes people who then run in trouble may ask a question on the mailing-list, and chances are the same question will have been asked many times before. But sometimes people are shaking their heads, left in awe and amazement (and a very real sense of discomfort) as they watch how poorly their brand new Play application performs. The trouble with Play, if I may say so, is that it has an entirely different approach to threading than traditional web-servers used on the JVM such as Tomcat, Jetty and friends. Those so-called threaded servers don’t call for questioning choices made in regards to blocking I/O operations, and therefore it is rather rare to see people concerned about how exactly the request pipeline works. If you’re a little concerned about performance and scalability however, chances are that at some point, the threaded model is not going to be good enough for you, and you may therefore look for another technology and stumble upon Play. At this point, you have entered a whole new world: in order to get really good performance out of your hardware, it takes a bit more effort. In order to write a truly performant application, that scales well in and out and will not crash (or not in such a way that users notice it) it is important to know how things work, and how to use Play well.

So this is what one part of the book is about. There’s a 50% discount running at the moment, the code is mlbernhardt . Grab it while it’s fresh!

责编内容by:In translation (源链)。感谢您的支持!


Reactive Microservices With Lagom and Java Section 1 Introduction This Refcard helps you wit...
Functional Reactive Programming with Angular and S... Functional reactive programming (FRP) is a variant of reactive programmi...
Tracing a reactive flow – Using Spring Cloud... Spring Cloud Sleuth which adds Spring instrumentation support on top of Open...
Processing Pipelines Series – Reactive Exten... Whereas TPL Dataflow is all about passing messages between blocks, Reactive Exte...
实战Spring Boot 2.0 Reactive编程系列 – WebFlux初体验... 上文引入了 反应式编程模型 相关概念,对 Spring Reactor 的核心 API 进行了简单归纳。本文会对 Spring 5 WebFlux 进行相关介...