NGINX Adds JavaScript Engine to Become Rules-Based Reverse Proxy – InApps Technology 2022

In an October 2014 interview with InfoWorld, NGINX Inc. founder Igor Sysoev dropped what should have been a bomb, if only anyone at the time knew how to detonate it: NGINX — essentially a proxy server, but what was fast becoming a critical component for microservices applications as a high-level load balancer — would be doing something big with JavaScript. When in November, it produced a configuration that could be used with Node.js, folks thought that must have been what Sysoev was talking about.

Not really. The bomb officially went off on Wednesday, as the company revealed it was producing its own JavaScript engine (as opposed to borrowing someone else’s, which would have been an option) to enable infrastructure developers to deploy sophisticated backend logic for routing requests to their servers. That engine would be deployed in what NGINX, at its own conference at Fort Mason Center in San Francisco this week, is describing as a “working prototype” of a new, logic-driven server.

The Ephemeral Interpreter

“It’s based on an entirely new JavaScript engine that we have created, and we are open-sourcing,” declares Owen Garrett, NGINX Inc.’s marketing chief, in an interview with InApps Technology.

“We looked at the current JavaScript engines available today — things like Google V8, [Mozilla] SpiderMonkey, and Apple’s JavaScriptCore,” Garrett continues.

“But they all were designed to work within a web browser. That design didn’t fit very comfortably inside NGINX, where we’re handling thousands more connections. And we wanted a JavaScript VM that we could start and stop very quickly, pre-empt, and control in ways that a web browser VM isn’t designed for.”

It’s easy to imagine a scenario where a single, centralized JavaScript engine is cast in the role of overseer of a vast empire of parallel connections. Because it’s easy, that’s the model you need to cast out of your mind.

Picture instead a model where each connection is marshaled by its own, tightly-coupled JavaScript VM, with each NGINX JS VM focused on its own little mission. That slims down each VM to a minuscule size, says Garrett. That’s different than a web browser-based JavaScript engine that is tasked with handling multiple connections while handling garbage collection (memory cleanup) jobs for the local client.

“The requirement that we have is not to have a single, monolithic JavaScript VM that handles lots of connections and switches between them,” Garrett explains, “but rather to have a very small, lightweight JavaScript VM that we can spin up for a connection when we need it, that we can pre-empt — meaning we can put it aside, and go handle other operations — that we can re-awaken, and then when that short operation is finished and the connection is completed, we just throw away the JavaScript VM.”

It’s an ephemeral interpreter whose lifetime is exactly that of the connection it’s monitoring.

Although technically the NGINX language, called nginScript, is based on JavaScript, it’s actually a subset of ECMAScript 6, with the intention of extending that subset in revisions to come. Since each VM has its own limited scope, theoretically, the connections themselves are infinitely scalable.

For now, the VM “listens” for events in a similar fashion to a web browser’s VM, but using a smaller memory model. But the depth of those events doesn’t have to go overboard, says NGINX Inc.’s marketing head.

“We conceal a lot of that internal complexity from the developer,” he says.

“The developer doesn’t need to be aware of the network events that are triggered by packets. Our JavaScript scheduling will hide that from the developer, so he or she will be able to write very simple, linear scripts using JavaScript syntax, and they won’t have to worry about scheduling events and the interactions between different connections. We want to abstract all that from the developer.”

Simple Logic

NGINX’s job up to now has been to terminate incoming IP traffic (acting as a destination point), examine packets, rewrite them where necessary, and apply authentication rules and content filters. “In our preview release,” Garrett goes on, “you’ll be able to add JavaScript logic to each of those stages, so you’ll be able to enhance the built-in capabilities of NGINX with JavaScript decisions.”

One example he offers involves the opportunity NGINX gets, when it’s processing traffic, to rewrite a request. First, a redirect is sent to a different location. Then the request is modified before it becomes proxied. (With Apache, there’s a way to do this using its .HTAccess configuration files, which NGINX does not support. But historically, infrastructure developers have avoided Apache’s rules handler for its poor performance.)

With nginScript, says Garrett, developers will be able to write sophisticated rewrite rules, each of which may scan large database tables. A logged-in user may have a cookie associated with her. If the cookie exists, the script may want to direct the rewrite request to a different URL than the one reserved for when such a cookie does not exist yet. Perhaps the logged-in user should be redirected to the home page.

“All of these capabilities may be implemented in a very simple fashion using nginScript,” he promises.

“It’s a very expressive language. If you can articulate what you want to do with the traffic, then it should be possible to implement it using JavaScript, because it’s a very flexible foundation for these sorts of rules.”

For now, NGINX’ version of JavaScript will not be capable of integration with the IDEs of choice used by professional JS developers. Owen Garrett repeated a few times during our discussion that NGINX Inc. is not interested in building a “JavaScript server,” nor should NGINX be portrayed as a server with its own JS engine. Rather, nginScript is intended for point solutions and very simple, scripted logic.

“But developers will still need to build the bulk of their applications the way that they always did,” he goes on, “using a separate set of tools. NGINX is the platform underneath that delivers the application, and nginScript allows you to customize and configure that platform in a more flexible and expressive way than you can do now.”

Feature image: “parallel worlds” by Alosh Bennett  is licensed under CC BY-SA 2.0.