It's sad to see lua get slowly replaced by javascript.
I have been playing around with Lua in Openresty for the last few nights. I haven't had any Lua experience before but it seems to be a good language for Nginx, and it has been fun to learn.
Launching NginScript
11–20 of 131 posts
Re: Launching NginScript
#12I'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 tryi…
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 specialized tools that will do their jobs well, and you probably have most of them in your stack anyway.
Granted, it's more complexity, but nginx certainly isn't the must-have that it used to be.
Re: Launching NginScript
#13The 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?
It's here: http://hg.nginx.org/njs/
Re: Launching NginScript
#14Re: Launching NginScript
#15For anyone interested, it looks like it's available as a module on http://hg.nginx.org/njs/
Re: Launching NginScript
#16It's sad to see lua get slowly replaced by javascript.
It is. But JavaScript is the new assembly language, all you need is a Lua to JS compiler or a whatever to JS compiler.
Re: Launching NginScript
#17It's sad to see lua get slowly replaced by javascript.
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.
Re: Launching NginScript
#18I'm really happy with openresty and curious to put them side by side. betting on lua here.
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?
Re: Launching NginScript
#19I'm really happy with openresty and curious to put them side by side. betting on lua here.
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 think this depends on just how compatible NginScript is with JavaScript. Will it be possible to pull in the ffi node module, or one of the many node redis modules?
Re: Launching NginScript
#20I'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 tryi…
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…
I don't know about the OP's reasons, but one of mine lately has simply been dependency management and simplicity of deployment. It's just handy to be able to package it all together, especially for packaged software where deploying another component would be more configuration. I suppose this is why docker containers (or in the past, virtual appliances/VMs) have become so much more popular.
The good embeddable web servers are usually pretty lightweight, scalable and can be programmatically configured. Things like Jetty are popular, but look at languages like Go that have HTTP serving built in via libraries and scale nicely via coroutines.
Vert.x etc. are cool for performance reasons, being lightweight and usually much less thread hungry (using async operations, sometimes in many less threads).
That said, I do agree that reverse proxies are still really useful for all the reasons you mentioned. Reverse proxies on top of some of these high performing embedded HTTP serving engines is a good practice, when you need it.
And there is no need to throw out the tried and true engines, like Apache, Nginx, etc.
Just depends on the use case and needs I suppose.