
Launching NginScript - donflamenco
https://www.nginx.com/blog/launching-nginscript-and-looking-ahead/
======
stanleydrew
I can't help but think this is a bad idea. Jamming more stuff into what is a
great tool puts nginx on a slow path to a bloaty death.

Am I incorrect in assuming that you could implement your entire server-side js
app now as an nginScript module? Do people think that is a good thing?

Not to mention that putting more interpreters and more end-user code into a
system that has access to your service's private key might not be terribly
wise.

I'm sure many people will tell me I'm wrong, and I guess I can see some
benefit to simplifying configuration and perhaps deployment.

But there's a reason we've mostly moved away from deploying embedded PHP
applications inside of mod_php.

~~~
CrLf
The usefulness of this is not to turn nginx into an application server.
Although there are already frameworks for this using ngx_lua
([http://leafo.net/lapis/](http://leafo.net/lapis/)), I don't find them very
interesting except for the technical aspect.

The point is to make nginx's configuration dynamic and prevent bloating
applications with stuff that belongs at the (lets call it) devops level.

Now, I also don't think nginScript is such a good idea. But because they seem
to be building their own JavaScript VM for it. I believe this is a waste of
effort and more of a JavaScript-all-the-things than anything else.

Lua is a very simple language, the VM is small and fast and for the "dynamic
configuration" scenario one hardly codes more than a few lines (I've done
quite a few things and the total line count is in the low 100's).

~~~
n42
It's funny. Any feature you don't want to use is bloat, but as soon as you
need it is a necessity. The way I see it, they can either "bloat" nginx by
adding scripting capabilities, or they can bloat it by covering all of the use
cases that a scripting engine would otherwise enable, big and small.

One simple example that I would love to use this for: generating and adding a
UUIDv4 to every request's headers. Doing so would allow us to append the UUID
to virtually every log in our entire stack. Right now there is no easy out of
box solution for this in nginx. With scripting capabilities it becomes
trivial.

However, whether or not Lua was enough and adding JavaScript is overkill, I'm
not sure.

~~~
erikcw
I've had the following Lua adding request UUIDs to our logs in production for
over a year. Feel free to give it a try:

[https://gist.github.com/erikcw/e999e1fb438dbbb91533](https://gist.github.com/erikcw/e999e1fb438dbbb91533)

------
jnbiche
I wonder why they didn't use Duktape[1]. It seems like the obvious choice for
this kind of effort (e.g., if the 2 main Lua implementations have any
counterpart in JS, it's probably Duktape).

It's possible that Duktape was still too early in its development to use when
Nginx started this project, but even then it seems like they could have
collaborated and saved a lot of man hours.

I wonder if there a good reason why Nginx didn't use Duktape, or could this be
a case of NiH where some Nginx dev got excited about the opportunity to build
a new superfast JavaScript implementation just for Nginx? Surely it would have
been less work to integrate the two event loops and use Duktape's (well-
documented) API to build whatever features they wanted?

That said, although I've built significant async programs in other languages,
I've never done anything in C on this scale, so take my words with a grain of
salt.

1\. [http://duktape.org/](http://duktape.org/)

~~~
jws
I've used duktape as an extension language and wholeheartedly recommend it. It
does the job and caused me zero problems. I can't ask for more than that in
software.

------
placeybordeaux
It's sad to see lua get slowly replaced by javascript.

~~~
ThinkBeat
I think is is sad to see anything replaced by Javascript. Unpopular opinion I
guess.

So many better choices out there.

~~~
accounthere
I for one like seeing Javascript replaced by better Javascript.

~~~
Maarten88
Better javascript would be incompatible with javascript - best you can get
will be "less sucking javascript". And you'll be able to use it somewhere in
the far future, after four competing companies have implemented enough of it
in a way that mostly works, their browsers have reached most of the internet
and the brave open source community has developed the polyfills needed to fix
the incompatibilities.

I'm not holding my breath. Javascript sucks, it will be everywhere and we are
stuck with it.

------
TazeTSchnitzel
This seems like massive overkill. Instead of adding a limited domain-specific
language which is tuned to nginx's requirements, they've added the behemoth
that is JavaScript, along with all its flaws. A turing-complete behemoth, at
that.

~~~
ksherlock
It's a subset of javascript, with a subset of flaws. The wiki entry
specifically mentions that eval and closures aren't supported.

~~~
wwweston
closures as in "first class function values"? Or closures as in scope that
follows a function from where it was defined?

------
lxfontes
I'm really happy with openresty and curious to put them side by side. betting
on lua here.

~~~
marktangotango
Two things;

The big HUGE win for lua in this, in my view, is the plethora of packages on
luarocks. With simple scripts, as presented in this blog posts, sure a
javascript subset is fine. But suppose you want to interact with redis from
your script? Where's the c ffi interface, and a prepared package you can use
from nginscript? Grap hiredis bindings from luarocks, and your set.

Second, great yet another javascript implementation. They're very open about
supporting a subset out of the gate, who knows how long it would take to reach
parity with es 5 or 6 even?

~~~
neomantra
I agree with what you said -- although the node/npm ecosystem is much bigger.
I'm not sure how it works with the nginScript subset.

But network-related libraries shouldn't be pulled from luarocks (unless maybe
they have resty in the name). One would want to use lua-resty-redis and not
hiredis within OpenResty. The 'resty' libs use the nginx cosocket library so
work asyncronously with nginx core. hiredis would block the worker threads.

~~~
marktangotango
Ah thanks, I was not aware of that. Also, unless they code nginscript to
specifically support googles V8 api, there's no reason to expect node or any
of it's packages to work with it.

------
graniter
This is a welcome improvement to me. I've spent many an hour trying to figure
out how to put some logic in nginx but it was never very intuitive to me. I
think a reverse proxy + ssl termination + web cache should be considered part
of a normal web stack and developers should be proficient to use the full
stack when they develop and implement sites. Rather than trying to do
everything on the app server, once I started utilizing nginx my app design
changed somewhat and of course the response times dropped and the app server
load was reduced. I'm hoping nginscript just makes it all easier to do.

------
mulander
A web server with a JavaScript engine. What could ever go wrong?

My eyes start to bleed when I imagine what some cowboys will implement on top
of that.

~~~
fanf2
Netscape Enterprise Server included server-side JavaScript in the 1990s.

------
Tenzer
The post ends with "We look forward to your feedback as you try out nginScript
[...]" but it doesn't mention where we can test it out. Does anybody know more
about that?

~~~
wut42
It's here: [http://hg.nginx.org/njs/](http://hg.nginx.org/njs/)

------
tambourine_man
_We run a separate virtual machine for each request, so there’s no need for
garbage collection_

I'm curious to see the impact of this strategy on performance.

~~~
Matthias247
I wondered about this sentence. If you would apply scripting functionality to
serve long-running websocket or HTTP/2 connections I'm sure garbage collection
would be necessary. However if the scripts are really per request and not per
connection then it could work - but the capabilites would be much more limited
then what you can do in other scripted-webserver-environments (e.g. node).

~~~
sitkack
A VM context could be cheap to create and include an amount of memory above
what that script uses for its lifetime. Meaning a single allocation and then
the whole thing gets free'd at the end of execution. Analogous to how CGIs
execute.

------
59nadir
I think a countdown for a new 'in vogue' webserver just started.

This is something I would've expected from a "Show HN: Embedded JS in Nginx"
post, meaning it has potential to be a project done just to see what can be
done, that everyone could say "Hey, that's cool" and then never use, because
it's a terrible idea.

Instead, it's presented as a reasonable way of moving forward, when they
could've pushed for their own much more reasonable alternative. They've done
more work for a worse idea, effectively out-competing their own feature with a
much more popular but crappy alternative.

------
mkup
Adding Javascript support to high-performance reliable web server does not
seem rational from the engineering point of view.

I'd rather added support for the safe subset of some statically-typed, high
performance language compiled to LLVM. This language must be without
asyncronous GC, so its memory use will be predicatable under high load.

Javascript on server side is so vogue-ish. Vogue will change soon but uglyness
of architectural decision will stay with Nginx forever.

------
eknkc
I think it's a good addition. We have been using varnish on high traffic
servers and one of the reasons was that it had "vcl", a javascript-like
language to define request handling logic. (With a lot smaller feature set and
more domain specific. But powerful enough). Having javascript on nginx would
provide a lot of config options for people familiar with it. I believe nginx
already has Lua support so not a big deal anyway.

~~~
girishso
I agree. It will be more easier to write some custom request handling logic in
Javascript.

------
jimjag
Yeah, I am a known Apache fanboy, and so I'm sure that what I say will be
discounted. But, imo, this just shows what happens when an open source project
becomes the sales initiative of an Open Core model company. Instead of the
design and future being under the control and guidance of the community, it is
instead in the hands of the VCs and whatever "promises" future revenue growth.
Believe me, I know; I used to work at Covalent which was billed as the "Red
Hat of the Apache web server" so I know how hard it is to resist the push of
VCs and those nasty quarterly numbers. And Covalent wasn't the only Apache
shop around, unlike nginx.com today.

The combination of FUD and marketing $$$ is being used to "encourage" more
people to migrate (or use) nginx, as an "open source" alternative, when it's
obvious that "open source" is being used mostly for the PR aspect and not so
much for the community-focus and community-led aspects which is really core to
"true" Open Source.

------
stonogo
nginx is driving very fast down the road to firefox.

~~~
ticktocktick
Marginal bloat is always rational. Forest for the trees and all that.

------
jessaustin
Should Greenspun's Tenth Rule be updated with a note that "they might try
adding javascript before they add common lisp"?

------
_Codemonkeyism
I can understand the appeal, marketing Javascript to CIO/CTO is much easier
than marketing Lua today.

(Which obviously is sad as in my humble opionion for various reasons Lua is
the better embedded language. I hoped it could become a widely adopted
standard, we had great success with Lua in Redis in the past).

------
ck2
as long as I can compile --without-nginscript, go nuts

------
wut42
For anyone interested, it looks like it's available as a module on
[http://hg.nginx.org/njs/](http://hg.nginx.org/njs/)

------
tootie
I've recently been leaning towards not using web servers like nginx or apache
at all. There are non-blocking server platforms like node.js or vert.x that
let you code your web server instead of configure it. I find that ou
frequently hit a wall of opaque redirect rules that become unmaintainable for
any complex project. Having your server written in testable code makes it more
predictable. It looks like nginx is trying to meet in the middle.

~~~
wasd
I'm not sure if this is great idea. Use of reverse proxies has lots of
benefits. You can manage load balancing, SSL Termination, serving static
content (much faster), caching, compression, centralized logging, and using
different applications on the same ur space (foo.com/app1, foo.com/app2). They
also have the added benefit of another layer of security (look for and prevent
various HTTP exploits and prevent them from getting to the web server). I'm
not saying you can't do this in node but nginx/apache are really good at what
they do.

EDIT:

I've read through your comments and you seem like a pretty experienced
developer. I don't think any of the information in my comment should be news
to you so I'm curious to hear more about why you feel this way.

~~~
kyledrake
I use nginx at Neocities to serve all our static sites, and as a proxy for our
front site.

I like nginx, but it has way too much of a sacred cow treatment by the dev
community. It has plenty of problems, the configuration is a psuedo-language
that doesn't always make the right choices and is difficult to heavily
customize, and I've gotten to it be -very- unstable under certain
circumstances, including really bread-and-butter things like SSL caching. If
there's a bug, you'll have a good old time debugging it's massive collection
of C code. It's great, but it's not perfect.

Making nginx do custom things that you'll probably need to do in a serious
environment (example: dynamically programmable SSL SNI) requires craxy mods
and hacks that have only recently been made available (by third parties) and
heavily reduce nginx's performance. Further, they only provide purgable proxy
caching via their commercial version, which costs an exorbitant amount of
money. The free purger, naturally, makes nginx lock up. I wouldn't mind
chipping in a bit for nginx because I want to support their team any way, but
at their current prices ($100/node/month or something like that) we simply
can't afford it.

I realize this is not a popular opinion right now, but node.js is completely
up to the task of running a reverse http proxy. They are basically (you likely
won't notice the difference unless you're running the New York Times)
competitive with nginx for performance, and as a tradeoff for an unnoticable
slowdown you get a full, turing complete programming language to completely
control the flow of your data. Nginx under the hood is just a reactor pattern
with children that share a socket. Node.js has a cluster module that uses the
exact same strategy. Mind you this is from someone that has done talks
critical of reactor pattern scaling.

Also, if you have blocking I/O apps, it doesn't matter what you configure
nginx to do, it's still going to lock up when someone DDoSes it with slow
loris connections. Make your ruby app thread safe and use Rainbows! instead of
Unicorn, or you're going to have a bad time.

~~~
bhouston
So when are you going to release "node-ginx"? :)

~~~
kyledrake
You're on to me. ;)

There is node-http-proxy available ([https://github.com/nodejitsu/node-http-
proxy](https://github.com/nodejitsu/node-http-proxy)), which also has some
plugins available to do some of the advanced features nginx supports.

I'll likely be writing a custom proxy server tailored to our needs such that
it probably won't be useful as a general purpose proxy server, but if you're
looking for something, that's a start. Making it more general purpose
unfortunately would require more work, and I'm pretty time stretched right
now.

I'm not saying it's better than nginx, of course. I'm just saying that if you
need to do some crazy programming that can't be done with nginx, you're free
to use something else. Don't be fearful of treading your own path, just make
sure you know well how HTTP works before doing it.

Here's a stupid example I whipped up quickly for a reverse proxy for our IPFS
nodes that demonstrates how quickly you can put together a custom reverse
proxy to do something weird: [https://github.com/neocities/hshca-
proxy/blob/master/app.js](https://github.com/neocities/hshca-
proxy/blob/master/app.js). That flaming piece of junk hasn't crashed once
since I deployed it.

~~~
tracker1
For that matter godaddy's website builder now "publishes" to a cassandra
cluster that is served via a cluster of node servers with local redis as a
local in-memory cache... it works really well. The distribution model is
working much better than the previous publishing via ftp to a dedicated
backend linux host (apache). I haven't been there for about a year now, but
I'm pretty sure a lot of those aspects have proven out.

------
paraboul
I think that most people missed the point here.

The basic idea is a DSL that "happens" to have the same syntax than
Javascript. I guess that this VM has a lot of optimisations related to its
purpose toward nginx (.e.g. no GC overhead, since each JS context is supposed
to be short lived and tied to a unique request).

------
mrbig4545
so it's mod_perl, but javascript and nginx instead of apache and perl. seems
like they've ignored history here, as mod_perl turned out to be a bad thing in
the end, people messing with bits they really shouldn't leading to massive
amounts of unmaintained legacy spaghetti code messing with all parts of
apache.

bearing in mind mod_perl's original use was not for writing applications, it
was for messing with apache, for doing the things you can't easily do in the
config. but where there's a way, abuse will follow, and before you know it
whole apps will be written with this

ah well, those who don't learn from history are doomed to repeat it.

so, while it may seem like a good idea now, you can bet in 5-10 years it will
no longer look so clever

------
vacri
I wonder if they'll have an "'nginscript' is evil" section in their wiki, like
their "'if' is evil" one...

------
s369610
I wonder if this has anything to do with the call for a new maintainer for
LuaJIT recently

~~~
bungle
No.

------
totony
As long as they add a --disable-js config flag i guess i'm okay with it

------
elcct
If you need that flexibility I think Go is much better solution.

------
kolev
Why not write a JavaScript to Lua transpiler instead?!

------
namelezz
Why did not they use Golang?

------
iamleppert
Dislike.

------
rwaldron
[https://www.youtube.com/watch?v=rX7wtNOkuHo](https://www.youtube.com/watch?v=rX7wtNOkuHo)

------
acd
I think Nginx is open source crippleware. All the goddies are in the closed
Nginxplus. Http2, load balancing with monitoring with application health
checks. Do you get the source code of the closed features?

Nginx already has LUA scripting support.

~~~
pnommensen
The HTTP/2 module of NGINX is (and has been) fully open source.
[https://www.nginx.com/blog/nginx-1-9-5/](https://www.nginx.com/blog/nginx-1-9-5/)

Disclaimer: I work at NGINX.

------
fideloper
HN and it's predictable level of antipathy is a constant disappointment.
Hating is the norm, do better. Put more thought into your opinions.

Personal feelings of Javascript aside (not my favorite either!), I think this
is a great business move (adoption, excitement, blog-o-sphere marketing, even
if some users shoot themselves in the foot), and I think it opens up exciting
possibilities, including creating Nginx+ features fo'free.

~~~
striking
Anything you can do in nginScript, you can do in Lua. Except that Lua was
lightweight to begin with. This isn't JS (as we know it), this doesn't get
access to the Node/npm/bower/whatever ecosystems.

The antipathy is a symptom of our JavaScript disease. We have grown tired of
this affliction. We understand now what makes it less great than we once
thought. The churn of rapidly growing and devolving JS frameworks, the slog of
awful design-by-committee processes putting the language together... it is
nothing compared to Lua's simplicity.

And some clever fellows understood this long ago, on a site much like this
one. Feel free to take a look.
[https://news.ycombinator.com/item?id=7890685](https://news.ycombinator.com/item?id=7890685)

