Introducing Play 2.0
Guillaume Bort
Since 2007, we have been working on making Java web application
development easier. Play started as an internal project at Zenexity
and was heavily influenced by our way of doing Web projects: focusing
on developer productivity, respecting Web architecture, and using from
the start a fresh approach to packaging conventions - breaking where
it made sense the so-called JEE best practices.
In 2009, we decided to share these ideas with the community as an open
source project. The immediate feedback was extremely positive and the
project gained a lot of traction. Today - after two years of active
development - Play has several versions, an animated community of
3,000 people, with a growing number of applications running in
production all over the globe.
Opening a project to the world certainly means more feedback, but it
also means discovering and learning about new use cases, requiring
features and un-earthing bugs that we were not specifically considered
in the original design and assumptions. During the two years of work
on Play as an open source project we have worked to fix all of these
kind of issues, as well as to integrate new features to support a
wider range of scenarios. As the project has grown, we have learned a
lot from our community and from our own experience - using Play in
more and more complex and varied projects.
In the meantime, technology and the Web have continued to evolve. The
Web has become the central point of all applications. HTML, CSS and
Javascript technologies have evolved quickly - making it almost
impossible for a server side framework to follow. The whole Web
architecture is fast moving towards real-time, and the emerging
requirements of today's project profiles means SQL no longer works as
the exclusive datastore technology. At the programming languages level
we've witnessed some monumental changes with several JVM languages,
including Scala, gaining popularity.
That's why we think it's now time to move on, and to consider the next
major version of Play. Welcome Play 2.0!
Native support for Java and Scala
---------------------------------
In Play 1.1, we started exploring the possibility of using the Scala
programming language for writing Play applications. We initially
introduced this work as an external module to be able to experiment
freely without impacting the framework itself.
Properly integrating Scala into a Java-based framework is not trivial.
Considering Scala’s compatibility with Java, one can quickly achieve a
first naive integration that simply uses Scala’s syntax instead of
Java’s. This, however, is certainly not the optimal way of using the
language. Scala is a mix of true object orientation with functional
programming. Leveraging the full power of Scala requires rethinking
most of the framework’s APIs. After several versions we now have a
clean Scala module that allows the use of most of Play's features from
Scala, in a Scala-ish manner.
Now, we are reaching the limits of what we can do with Scala support
as a separate module. Initial design choices we made in Play 1.x,
relying heavily on Java reflection API and byte code manipulation,
have made it harder to progress without completely rethinking some
essential parts of Play’s internals. Meanwhile, we have created
several awesome components for the Scala module, like the new
type-safe template engine and the brand new SQL access component
Anorm. So we have decided that, to fully unleash the power of Scala
with Play, we are moving Scala support from a separate module to the
core of Play 2.0, which will be designed from the beginning to
natively support Scala as a programming language.
Java, on the other hand, is certainly not getting any less support
from Play 2.0; quite the contrary. The Play 2.0 build provides us with
an opportunity to enhance the development experience for Java
developers. Backed by our experience throughout the project we have a
clear idea of what we need to achieve and what mistakes we have to
avoid.
Powerful build system
---------------------
From the beginning we have chosen a fresh way to run, compile and
deploy Play applications. At the time it may have looked like an
esoteric design - but it was crucial to providing an asynchronous HTTP
API instead of the standard Servlet API, short feedback cycles through
live compilation and reloading of source code during development, and
promoting a fresh packaging approach. Consequently, It was difficult
to make Play follow the standard JEE conventions.
Today, this idea of container-less deployment is more and more
accepted in the Java world. It's a design choice that has allowed the
Play framework to run natively on platforms like Heroku, which
introduced a model that we consider the future of Java applications
deployment on elastic PaaS platforms.
Existing Java build systems, however, were not flexible enough to
support this new approach. Since we wanted to provide straightforward
tools to run and deploy Play applications, in Play 1.x we created a
collection of Python scripts to handle all build and deployment
related tasks.
But developers using Play for more enterprise-scale projects, which
require build process customization and integration with their
existing company build systems, were a bit lost. The Python scripts we
provide with Play 1.x are in no way a fully featured build system and
are not easily customizable. That's why we've decided to go for a more
powerful build system for Play 2.0.
As we need a modern build tool, flexible enough to support Play
original conventions and able to build Java and Scala projects, we
have chosen to integrate SBT in Play 2.0. This, however, should not
scare existing Play users who are happy with the simplicity of Play
build. We are leveraging the same simple play new, run, start
experience on top of an extensible model: Play 2.0 will come with a
preconfigured build script that will just work for most users. On the
other hand, if you need to change the way your application is built,
deployed, etc., a Play project being a standard SBT project will hand
you all the power to customize and adapt it to your special needs.
This also mean better integration with Maven projects out of the box,
the ability to package and publish your project as a simple set of jar
files to any repository, and especially live compiling and reloading
at development time of any depended project even for standard Java or
Scala libraries projects.
Focused on type safety
----------------------
One benefit of using Java as programming language for writing Play
applications is that the Java compiler can check certain parts of your
code. This is not only useful for detecting mistakes early in the
development process, but it also makes it a lot easier to work on
large projects with a lot developers involved.
Adding Scala to the mix for Play 2.0, we will clearly benefit from
even stronger compiler guarantees - but that’s not enough. In Play
1.x, the template system is dynamic, based on the Groovy language, and
the compiler can’t do much for you. As a result, errors in templates
can only be detected at runtime. The same goes for verification of
glue code with controllers.
We really want to push further this idea of having Play check most of
your code at compilation time in the 2.0 version. Accordingly, we have
decided to use the Scala based template engine as the default for Play
applications - even for developers using Java as the main programming
language. This doesn't mean that you have to become a Scala expert to
write templates in Play 2.0, just like you were not really required to
know Groovy to write templates in Play 1.x. Scala will be mainly used
to navigate your object graph in order to display relevant information
with a syntax that is very close to the Java one. However if you want
to unleash the power of Scala to write advanced templates
abstractions, you will quickly discover how Scala, being expression
oriented and functional, is a perfect fit for a template engine.
And that's not only true for the template engine: the routing system
will also be fully type-checked. Play 2.0 will check all your routes'
descriptions, and verify that the everything is coherent, including
the reverse routing part.
As a nice side effect, being fully compiled, the templates and route
files will be easier to package and reuse and you can expect high
performance gain on these parts at runtime.
Built for asynchronism
----------------------
Today's web applications are integrating more concurrent realtime
data, so web frameworks need to support a full asynchronous HTTP
programming model. Play 1.x was initially designed to handle classic
Web applications with many short lived requests. But now, the event
model is the way to go for persistent connections - though comet,
long-polling and WebSockets.
Play 1.2 already provides great asynchronous HTTP support and
WebScokets using continuations. Play 2.0 will be architected from the
start under the assumption that every request is potentially long
living. We want, for instance, to generalize Controller and
WebsocketController concepts into one single simple model that fits
all needs.
But that’s not all: we also need a powerful way to schedule and run
long running tasks. Although the original Play 1.0 Jobs model was
introduced for this, we really need something more powerful and
robust. The Actor based model is unquestionably the best model today
to handle highly concurrent systems, and the best implementation of
that model available for both Java and Scala is Akka - so it's going
in. We will be introducing native Akka support for Play applications,
making it possible to write highly distributed systems.
Datastore and Model integration
-------------------------------
Datastore is no longer synonymous with "SQL database", and it probably
never was. A lot of interesting models of datastores are becoming
popular, providing different properties for different scenarios. For
this reason it has become difficult for a Web framework like Play to
make bold assumptions regarding the kind of datastore that will be
used by developers. A generic play.db.Model concept in Play no longer
makes sense, since it is almost impossible to abstract over all these
kinds of technology with a single API.
We want to make it really easy in Play 2.0 to use any datastore
driver, ORM, or any another database access library without any
special integration with the Web framework. We simply want to offer a
minimal set of helpers to handle common technical issues, like
managing the connection bounds. We also want, however, to maintain the
full-stack aspect of Play framework by bundling default tools to
access classical databases for users that don't have specialized
needs.
Today, the preferred way for a Play Java application to access an SQL
database is the Play Model library that is powered by Hibernate. But
since it's annoying in a stateless Web framework like Play to manage
stateful entities such as the ones defined in the official JPA
specification, we have provided a special flavor of JPA keeping things
as stateless as possible. This forced us to hack Hibernate in a way
that is probably not sustainable in the long term. To address this, we
plan to move to an existing implementation of stateless JPA called
EBean. If you don't care too much about what is used under the hood
then it will change almost nothing for you, but if you really want to
use Hibernate or even another official JPA implementation you will be
able to do it without any special integration with Play. And if you
are using Scala we will continue to bundle Anorm.
Changes for current Play users
------------------------------
Play 2.0 will be a major release so it is unlikely that it will be
compatible at the API level with previous versions. Of course at the
architecture level you will find the same set of components, organized
in the same way, and most importantly, you will live the same 'Play
experience'.
What about my existing Play applications? How difficult will it be to migrate?
Don't worry, we don't expect you to migrate your existing applications
to Play 2.0. The Play 1.x versions will continue to be maintained and
you don't need to move to Play 2.0. We ourselves have many Play 1.x
web applications running and we will of course continue to support
them.
Remember: Play 1.2.3 is still the best way to write Web applications
in Java while Play 2.0 is still under development, and will continue
to be maintained and developed by the core team and contributors. Play
2.0 is an opportunity to move to for your next project, or the next
major rewrite of your application.
Getting started
---------------
Play 2.0 is still under heavy development and APIs are likely to
change, but you can already have a look to our preview versions. We
have set up a new GitHub repository to host the development, and we
have released a first preview version.
On the dedicated page at http://www.playframework.org/2.0, you can
track progress on this exiting project.
Have fun!
--
Guillaume Bort, http://guillaume.bort.fr
GrailsDeveloper
that sound like a good new direction for play. Would be great to have
the possibility to use the Scala-Template right now in a java-play-
project. Perhaps someone can show how this is possible. This enables
to avoid a migration of the templates.
2 question are still open to me:
1. Will the new framework mainly developed in Scala? I think this is
an important issue, because at the moment it's really easy for an
experienced java developer to analyze the code and create patches. How
will it be in the future? In other words, will you try to write as
much code as possible in Java and use only Scala where necessary or
the other way around?
2. CRUD based at the moment bold on JPA. Will there be a CRUD-Module
in the future?
Wish you great luck and a quick progress on Play 2.0. A beta at the
end of the year sounds great to me.
Niels
Pascal Voitot Dev
I have the same questions as Niels.
Moreover, when you foresee to integrate EBean, please also think about other frameworks (mine is siena as you may know) which will need to be integrated and do not wire everything too much tightly. In an ideal world, I would like to be able to remove completely EBean if I don't want it and replace it by Siena!
Anyway, I'm eager to see next steps and if you need help, don't hesitate to ask!
regards
Pascal
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
Bing Ran
Bing
Guillaume Bort
> an important issue, because at the moment it's really easy for an
> experienced java developer to analyze the code and create patches. How
> will it be in the future? In other words, will you try to write as
> much code as possible in Java and use only Scala where necessary or
> the other way around?
Most part of the core (HTTP and asynchronous invocation handling) will
be written in Scala, because it is really easier and more robust
(avoiding mutable states in this part will just make it easier to
debug and maintain).
But all the Java related API will be written in Java. Because we want
to provide an idiomatic API for Java and not force Java developers to
deal with Scala types. Also we want to have a clean Javadoc for the
Java API.
> 2. CRUD based at the moment bold on JPA. Will there be a CRUD-Module
> in the future?
I don't think so, or perhaps as an external module for particular ORM.
But trying to provide an unified CRUD module for all persistence
engines we can imagine is way too difficult. Anyway I think that the
current CRUD module is not flexible enough. It mainly solve the need
of writing a lot of repetitive screens, but It think it can be solved
with a better form/paginated list, tag components instead. But nothing
is decided yet.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>
--
Guillaume Bort, http://guillaume.bort.fr
Guillaume Bort
> frameworks (mine is siena as you may know) which will need to be integrated
> and do not wire everything too much tightly. In an ideal world, I would like
> to be able to remove completely EBean if I don't want it and replace it by
> Siena!
It exactly what we count on. That's why, even if we provide a default
ORM for Java to keep the fullstack aspect of Play, allowing users to
create quickly web applications, we won't integrate it too much with
the other parts of the framework. It is really important for us that
we can use whatever persistence engine you want with Play 2.0, without
need to hack it.
Please track the progress, and if you think that we make choice that
could limit integration with other persistence engine, in particular
Siena, tell us!
Pascal Voitot Dev
> Moreover, when you foresee to integrate EBean, please also think about otherIt exactly what we count on. That's why, even if we provide a default
> frameworks (mine is siena as you may know) which will need to be integrated
> and do not wire everything too much tightly. In an ideal world, I would like
> to be able to remove completely EBean if I don't want it and replace it by
> Siena!
ORM for Java to keep the fullstack aspect of Play, allowing users to
create quickly web applications, we won't integrate it too much with
the other parts of the framework. It is really important for us that
we can use whatever persistence engine you want with Play 2.0, without
need to hack it.
great :)
Please track the progress, and if you think that we make choice that
could limit integration with other persistence engine, in particular
Siena, tell us!
Yes now that Siena is near its final version 1.0.0 (just need mongoDB impl to definitely prove the design works), I will look at play2.0 a bit nearer and will tell you if I see any problems... Your scala evolution will certainly help me to develop the Siena4Scala also!
Pascal
Guillaume Bort
2 different versions would be terribly difficult. It's already the
case currently with the Scala module that is always behind the main
framework.
We prefer to merge efforts to provide a single perfect framework that
will support Scala and Java independently.
Pascal Voitot Dev
Now that I know better Scala (and love it more and more), I know that you can write the core in Scala and make it fully available to any Java application and provide some external full-Java APIs without any problem.
The only drawback is for people who liked to modify the code and now they will need to know Scala. But anyway, I agree with you, maintaining 2 frameworks would be crazy!
pascal
Hristo Deshev
Guillaume Bort
> guess nobody likes the idea of having a completely different Play framework.
> I hope you guys are able to define a clear migration path for 1.2.3. users
> that want to move to 2.0. Especially the ones like me that use the Scala
> plugin.
If you are using the Scala module currently, the migration path to
Play 2.0 will be easy. The most important change that will make
migration to Play 2.0 difficult is the new type safe template engine.
But if you are already using it it will be easy.
> One question - will play-scala 1.x eventually move to Scala 2.9.1? I hope
> that feature isn't planned for the 2.0 version only.
Problem is that Scala 2.9.0 breaks the Java reflection API (they done
it for good reasons however). So migrating the Scala module to 2.9.x
breaks almost everywhere it uses Java reflection API(binding,
fixtures, etc.). It's almost impossible to migrate without rewriting
these parts.
Ivan Meredith
I see anorm hasn't bean ported yet... btw, I take it you meant ebean
for java, anorm still preferred for scala?
Dave Cheong
Michael Boyd
Play 2! I'm sure it will be great.
However, can I make one suggestion? Don't re-invent the wheel with
type-safe declarations in the Scala templates.
Instead, I think you should use the declarations used in a popular JS
templating library -- preferably Closure Templates/Library.
I do this right now in tags and views, and it makes converting to
Closure Templates much easier:
*{
@param {String} _title
@param {Collection} _items
@param {play.mvc.Router.Route?} _pageLoadUrl (the ? indicates
optional)
}*
...the actual template here...
<h1>${_title}</h1>
Rakesh Waghela
Ivan Meredith
https://github.com/playframework/Play20/blob/master/play
On 8 September 2011 00:02, Rakesh Waghela <java...@gmail.com> wrote:
> Windows is not supported yet ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/4WHeNxHSXCAJ.
Daryl
I am going to disagree with some people here, and make a plea to go
the extra mile to make upgrades from old versions as painless as
possible.
You are obviously trying to move things forward, but don't annoy
existing users. We have been using play for live client projects since
version 1.0.1, we are currently running all live applications
(currently about 20) on 1.0.3.3. We have already struggled to upgrade
to 1.2.3 due to fairly large API changes, which in many cases could
have been minimised by keeping some backwards compatible methods while
still adding the new functionality. But the changes have been quite
ruthless and constantly having to revisit old code to upgrade play
versions is a pain many commercial developers could do without. Yes we
can leave applications on the old version, but by deprecating methods
and having them point to newer versions is much nicer for developers
than ruthlessly dumping them. We often want to utilise some of the
fixes & new features, but don't because of the pain to upgrade an
application to support a newer version.
We are not all playing at this (excuse the pun), we are trying to run
commercial development businesses, and don't want to be penalised for
being an early adopter by people taking theoretical high ground on
backwards compatibility. Backwards compatibility is price that
successful and stable projects have to live with. I appreciate this is
major version we are talking about here, but the more consideration
for this the better.
So having said that, and with all the talking of making things modular
and plug and play etc. Can things such as the database/storage plugin,
and template languages all be managed as modules. If you could do
this, it would make an upgrade easier, by selecting the JPA/hibernate
module and Groovy template modules as default (per application, not in
Play itself), then the upgrade path will be simpler. Then if you could
specify the database and template settings in an annotation per
controller, it would allow existing code to run, while gradually
converting and creating new functionality on the new modules.
I guess this was rather long and rambling, but essentially, please be
very careful with this. Many of us live in the real world, not fantasy
play land, we need to keep up with latest versions, so make the
upgrade path as simple as possible. I don't always think this happened
with Play. To continue its success, I think it is needed.
Also any ETA on this? It is on my schedule to put the leg work in to
upgrade to Play 1.2.3 over the next couple of months. Is it even worth
doing this? If there is going to be no more substantial development on
the Play 1 branch, I will stick with 1.0.3.2, and only consider the
move to Play 2.
thanks
Daryl.
Guillaume Bort
>
> I see anorm hasn't bean ported yet... btw, I take it you meant ebean
> for java, anorm still preferred for scala?
It is what will be provided out of the box in the fullstack approach.
But nothing will prevent you to use anything else, either Java or
Scala based.
Guillaume Bort
> type-safe declarations in the Scala templates.
We don't want to reinvent the wheel. The whole approach and syntax is
borrowed from ASP.net Razor template engine. And signature declaration
are just plain Scala declaration.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>
--
Guillaume Bort, http://guillaume.bort.fr
Guillaume Bort
compatibility without adding a lot of complexity to the project.
What's matter for us is to continue to support and maintain the
previous versions that are already running so many applications. And
we will do it. As you know, when we had the security alert lately, we
fixed all versions, including the 1.0.3.x. And we will continue to do
it, even after the 2.0 release. We have also a lot of applications
running on Play 1.x and we will surely not rewrite them all, or
abandon them.
If you have already several applications running on Play 1.0.3.3 for
your customers, it's fine, there is no need to migrate them. Just
consider 2.0 for you next project, or if it's worse it for a
particular application.
On the other hand, I'm sure than once the 2.0 version will be ready,
the community will help to port the current Groovy template engine or
JPA based Model API as Play 2.0 modules to ease migration of old
projects. It should be fairly easy, just for now we want to focus on
developing the core of the next major version.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>
--
Guillaume Bort, http://guillaume.bort.fr
zka
it sounds great.
I already download the preview, for some reason i prefer java, so
with the new scala template engine, it is possible to place view in
folders ?
views/
my_folder_as_controller_name/
index.scala.html
another_controller_name/
index.scala.html
?
Daryl
I think the point I was hoping to make, is that the work on making
storage/template functionality pluggable is the key here, then having
modules for Play 1 compatibility is the obvious stepping stone for
upgrades. I would expect the compatibility modules to come later,
ensuring this support and ease of use/configuration is my biggest
concern.
The added bonus of being able to configure this on a controller basis
would also help, allowing the changes to be made over time, while
still supporting the newer options. Is selection of storage/templates
using an annotation per controller an option? If this could be built
in at this early stage, then it gives much more flexibility for
applications to be gradually upgraded? I have seen previous requests/
questions on here, that would have been possible by selecting module/
plugin options per controller, so I think any consideration for this
would be appreciated.
thanks
Daryl.
T.J. Crowder
Sounds very exciting! Don't let either of the following detract from
the main point that this sounds cool, and it's fantastic to see Play
moving forward, unlike so many projects that get a couple of years in
and just...stop. Clearly not the case here!
I'm sorry to hear you're rewriting a lot of the core in Scala because
it's not a language I know and I have an irrational bias toward
languages that are syntactically derived from B (so C, C++, Java,
JavaScript, C#, etc.). I realize I don't have to know Scala to create
Play apps, but I liked the idea of being able to get my hands dirty on
the internals as necessary (and hopefully contribute back). But I
guess either I'll have to not do that, or I'll have to bite the bullet
and learn a new language. (I've been doing this for well over 20
years, it won't be that much of a problem.)
Since you're going to be doing a lot of work in the source, could I
put in a request for *ALL* public API methods and fields to be fully
Javadoc'd? With more than one-liners (or one-liners linking to the
appropriate further documentation), ideally, but in many cases the
current API docs have no descriptions in the Javadoc at all, or such
minimal ones that they may as well not be there (the annotations in
particular suffer here).
I'm not complaining. Play is clearly a great framework and there is a
fair bit of documentation, but if you're going to be kicking around in
the source *anyway*, improving the Javadoc as you go could be a big
win.
Cheers -- and best of luck with Play 2!
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com
Guillaume Bort
> would also help, allowing the changes to be made over time, while
> still supporting the newer options. Is selection of storage/templates
> using an annotation per controller an option? If this could be built
> in at this early stage, then it gives much more flexibility for
> applications to be gradually upgraded? I have seen previous requests/
> questions on here, that would have been possible by selecting module/
> plugin options per controller, so I think any consideration for this
> would be appreciated.
No need annotation for that. It will clearly be different API, so if
you use a statically compiled template it will just be a standard
method call, but if you want to evaluate a Groovy template (if a port
if available in 2.0) you will just have to call render()
Arthur
I've just been looking through the kiki sample code; not downloaded it
yet as I'm currently at work. In the views, the controllers package
is being imported using the line
@import controllers._
Couldn't the controllers always be imported by default; so that this
piece of boilerplate isn't needed at the beginning of every view.
See https://github.com/playframework/Play20/blob/master/samples/kiki/app/views/hello.scala.html
for example.
>
> read more »
Guillaume Bort
> piece of boilerplate isn't needed at the beginning of every view.
Probably, nothing is final yet. But in 2.0 we will not block users to
use another namespace for controllers anyway.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>
--
Guillaume Bort, http://guillaume.bort.fr
jgeiger
Pascal Voitot Dev
> Couldn't the controllers always be imported by default; so that thisProbably, nothing is final yet. But in 2.0 we will not block users to
> piece of boilerplate isn't needed at the beginning of every view.
use another namespace for controllers anyway.
the most boring IMO are the implicits also... quite verbose
Guillaume Bort
> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/H7nsQLwGxQkJ.
will
This is a fantastic release, especially with the native support for
Akka and async request.
Slightly off topic, does anyone know the comparison between Akka and
Node.js in term of memory consumption per connection, max connections
supported, and message latency? I'm investigating using Node.js for a
project with large number of connections but small message data set
(e.g. 100K idle connections per node but hundreds of bytes messages
occasionally to 1K connections). Thanks.
