Live data from Hacker News

Launching NginScript

nginx.com

41–50 of 131 posts

Re: Launching NginScript

#41

Earlier quoted context omitted.

There is already Lua support so this is just adding another language - thus if this is a bad idea, it is a continuation of an existing bad idea, rather that starting a new bad idea. If that makes a difference....

Yeah I've been skeptical of nginx's Lua support in the past. I guess I discounted it because it was a relatively unknown feature and Lua is obviously not nearly as popular as JavaScript. I don't know of any production service written exclusively in Lua, though I'm sure there are some. So yes while this is just a continuation of a bad idea, it's a rather substantial continuation. I fear that a lot more people will mak…

OpenResty is built on Nginx's Lua support and is fairly popular. You're probably using websites that use it without knowing it.

Re: Launching NginScript

#42

Earlier quoted context omitted.

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-an…

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

You're on to me. ;)

There is node-http-proxy available (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. That flaming piece of junk hasn't crashed once since I deployed it.

Re: Launching NginScript

#43

Earlier quoted context omitted.

There is already Lua support so this is just adding another language - thus if this is a bad idea, it is a continuation of an existing bad idea, rather that starting a new bad idea. If that makes a difference....

Yeah I've been skeptical of nginx's Lua support in the past. I guess I discounted it because it was a relatively unknown feature and Lua is obviously not nearly as popular as JavaScript. I don't know of any production service written exclusively in Lua, though I'm sure there are some. So yes while this is just a continuation of a bad idea, it's a rather substantial continuation. I fear that a lot more people will mak…

AFIAK, CloudFlare is entirely just Nginx+Lua scripts.

Re: Launching NginScript

#44

Earlier quoted context omitted.

There is already Lua support so this is just adding another language - thus if this is a bad idea, it is a continuation of an existing bad idea, rather that starting a new bad idea. If that makes a difference....

Yeah I've been skeptical of nginx's Lua support in the past. I guess I discounted it because it was a relatively unknown feature and Lua is obviously not nearly as popular as JavaScript. I don't know of any production service written exclusively in Lua, though I'm sure there are some. So yes while this is just a continuation of a bad idea, it's a rather substantial continuation. I fear that a lot more people will mak…

I have read that cloudflare uses nginx lua a ton. Apparently so does taobao (via tengine?).

Re: Launching NginScript

#45
post #17

Earlier quoted context omitted.

It is. But JavaScript is the new assembly language, all you need is a Lua to JS compiler or a whatever to JS compiler.

Last I checked Javascript implementations were slower than LuaJIT. Cost of implementing Lua tables, meta-tables, co-routines, etc. in Javascript will be rather high. Anywhere between 2-50x. If native Lua engine is removed, you can just forget about it then. So what you're saying doesn't make any sense for anything remotely performance sensitive.

lua compiled to asm.js is 64% of the speed of lua native

https://kripken.github.io/lua.vm.js/lua.vm.js.html

Re: Launching NginScript

#46
post #41

Earlier quoted context omitted.

Yeah I've been skeptical of nginx's Lua support in the past. I guess I discounted it because it was a relatively unknown feature and Lua is obviously not nearly as popular as JavaScript. I don't know of any production service written exclusively in Lua, though I'm sure there are some. So yes while this is just a continuation of a bad idea, it's a rather substantial continuation. I fear that a lot more people will mak…

OpenResty is built on Nginx's Lua support and is fairly popular. You're probably using websites that use it without knowing it.

There's also Lapis, a really great and reasonably feature-full web app framework for OpenResty: http://leafo.net/lapis/. I wrote a website in it recently and was pleasantly surprised at how cool it is. It reminds me a lot of Rails, but everything works faster, especially on LuaJIT, and I actually like MoonScript (the compile-to-Lua language I'm using) for its expresiveness and aesthetics. Definitely recommend checking it out.

Re: Launching NginScript

#47

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 no…

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/), 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).

Re: Launching NginScript

#48
post #3

Earlier quoted context omitted.

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 fro…

To play devil's advocate (not that OP is an devil), you want a CDN serving up static assets anyway, and maybe take care of SSL termination and security depending on your sensitivity needs; haproxy is great for load balancing and centralized logging; vulcand to handle reverse-proxying; and at that point, all you're left with is compression, which a reasonable web server should be able handle. Now you've got a suite of…

HAProxy can do the SSL termination, reverse proxying, and compression jobs quite well by itself. Though vulcand's etcd-based runtime configuration looks friendlier than HAProxy's.

Re: Launching NginScript

#49

Earlier quoted context omitted.

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 im…

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 t…

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.

Re: Launching NginScript

#50
post #41

Earlier quoted context omitted.

Yeah I've been skeptical of nginx's Lua support in the past. I guess I discounted it because it was a relatively unknown feature and Lua is obviously not nearly as popular as JavaScript. I don't know of any production service written exclusively in Lua, though I'm sure there are some. So yes while this is just a continuation of a bad idea, it's a rather substantial continuation. I fear that a lot more people will mak…

OpenResty is built on Nginx's Lua support and is fairly popular. You're probably using websites that use it without knowing it.

We use the lua support in openresty to build our authentication layer for admin tools outside of those admin tools. Very easy to integrate it with a third party authentication platform and just provide auth for free to our app developers.
Post reply on HN