Leveraging Nashorn at Netflix

Netflix recently hosted the Silicon Valley Java User Group to talk about Nashorn, The Hidden Weapon of JDK 8. In this presentation the Netflix Partner Tools team described how they've started leveraging JavaScript in their services.

Netflix senior software engineer Matt Sun explains how they've used JavaScript to write test plans that test all of their features (such as 3D movies, Dolby Sound, HD/4K), as well as their thousands of different partner products. The product used to test all these combinations is called "Netflix Test Studio".

First deployed in 2012, Test Studio runs over 15,000 tests each day on over 400 devices around the world. The current generation tool, supporting dynamic lists of test cases based on devices, is a large change from the original static test-plan only version. The latest version is built on Nashorn, with interfaces to get test metadata and device properties. Test plans are then dynamically generated for features like 4K and 3D. This new event driven system is using WebSockets as the protocol. The rules for tests are written in JavaScript, which testers can open and edit in their browser. This allows immediate code and plan validation.

Sun also describes how they developed a Nashorn Analytics Engine to provide users, teams and companies visibility and insight into their data. The move to JavaScript to power their analytics engine has allowed them to eliminate the need for backend developers. Teams no longer need to wait for reports, they can modify them on their own. Also, the dynamic nature of JavaScript allows users to get immediate feedback from their changes.

In a recent article entitled Node.js and io.js on Java Oracle Product Manager Erik Costlow says that JDK 8, update 40 will contain improved JavaScript performance via optimistic typing. He also mentions Avatar.js, a project to bring the Node.js programming model, APIs and libraries to the Java platform. Advantages to running JavaScript applications on the JVM include scalability, manageability, tools and the lush garden of open source and proprietary Java libraries. Monitoring can be done with JMX or with specific tools like Java Flight Recorder and Mission Control.

Costlow writes there are also other ways to run Node.js application on the JVM, using RedHat's Nodyn or Apigee's Trireme.

John R. Rymer, Principal Analyst at Forrester Research, recommends Java developers learn JavaScript in 2015. In Java in 2015: Predictions and More, Rymer says:

Server-side JavaScript is going to present a lot of opportunity for Java developers this year ... And for .NET/C# people. There's sort of a lot of bleeding away in this direction. There's a lot of JavaScript on the client, of course, but most of the Java people I talk to are working on the server side. I think there's going to be a lot of demand for people who can bring knowledge of server-side architectures to bear using JavaScript. It's going to be a good skill to have.

To learn more about Netflix's use of JavaScript on the server, InfoQ sat down with Chris Saint-Amant and Peter Hausel, both managers on front-end teams; Saint-Amant on the website, Hausel on the metrics and testing applications.

InfoQ: Can you please give our readers some context around your JavaScript usage?

Saint-Amant and Hausel: Basically, there are two sides to our usage of Javascript at Netflix: 1) for the customer-facing stuff (member and non-member experiences -- catalog and sign-up flows) and 2) for gathering metrics from devices.

The first case is the website UI layer, which is undergoing a total re-write from a legacy Java application to Node.js. It doesn't run on the JVM at all, and has split the legacy Java app into several microservices. It integrates into the Netflix infrastructure through a Java-based sidecar agent on the server, where it get free interoperability with our service discovery, dynamic properties services, and metrics tooling. Presently, the Node.js apps at Netflix power a growing portion of the website UI, with wider usage across many customer-facing experiences planned.

The second case is all about capturing metrics and running active tests against devices to ensure the user experience is the best possible. In this case, the tests themselves are written in JavaScript because many of the devices that service Netflix (phones, smart TVs, etc.) are just wrappers for a JavaScript application. The tests that are written are then compiled within a Java-based web service that leverages Nashorn and AvatarJS (formerly "node.jar"). Their integration with Nashorn is strictly in this context, not as any full JS service on the JVM.

InfoQ: Do you intend to move your server-side code to Node.js?

Hausel: Our current strategy with Test Studio is to keep the core in Java while exposing certain APIs via Nashorn and perhaps Node in the future.

InfoQ: How many Node.js applications does Netflix have in production?

Hausel: I can't really tell the exact number but I do know many teams who run Node, one way or another.

InfoQ: How many of those applications run on the JVM vs. Node itself?

Hausel: In the case of Netflix Test Studio, all apps are running on top of the JVM.

InfoQ: Does Netflix have server-side JavaScript applications that run on something other than Node.js?

Hausel: We are experimenting with Avatar.js and Flow on top of Nashorn. Most of our apps are utilizing Nashorn. You can find some of our demos here.

InfoQ: Has the JVM's monitoring and scalability helped maintain your Node.js applications running on the JVM?

Hausel: Our biggest Nashorn issues were related to ScriptEngine isolation.

InfoQ: What's the biggest pain point of running Node.js applications on the JVM?

Hausel: JVM startup time and no precise control over script cache. Oracle is aware of these issues. The upcoming version of Nashorn will address some of these issues.

InfoQ: Any additional advice for developers or companies looking to run their Node.js applications on the JVM?

Hausel: While the npm ecosystem is huge, many extensions are relaying on native bindings (which need to be replaced with Java libraries). The biggest advantage really is being able to use a dedicated thread pools for CPU bound code. That said, Nashorn's multi threading story is another area where we hope to see some improvements coming from Oracle. The WebWorker compatible API (mentioned in the linked blog post) would be a step in the right direction.