NGINX Open Source: Reflecting Back and Looking Ahead
nginx.com
nginx.com
I'm sad to hear about JS; I thought the work with Lua was going well and would be a better candidate. Maybe I misunderstand the situation.
Nginx is one of those great tech that just makes so much more easy in my life.
I had a chat during an interview with folks from the Nginx team recently and definitely got the impression they are putting a lot more thought into the separation of Plus than this. One of the key features is the ability to add/remove backends at runtime, as well as, IIRC, some failover capability that makes Nginx Plus a potential competitor for things like F5.
Disclaimer: I am not associated with Nginx, except that I shook some folks hands, and I might have remembered something wrong. They went out of their way to illustrate to me, and I think they did, that Nginx Plus is more than just 'open core'.
If you read the prior article, linked in this one, the original author of Nginx is allowed to expound on this himself. An experienced Ops team can assemble a number of open-source components and custom code to accomplish some of the more advanced functionality in Nginx Plus, but I think it's saving more than a couple hours of customization. :)
Can you elaborate? I'm able to do almost everything with haproxy, including hot reloads, client-based SOA, frontend/backend traffic. I'm not sure what Nginx Plus gets me on top of that.
Disclaimer: From an ops team.
You can use JavaScript inside Postgres, for example, which makes it extremely versatile as a glue language for back-end services.
Lua has nowhere near the traction or support. Is there a C++ to Lua compiler that produces performant code when using an asm.js-like layer? Is Lua Rocks anywhere near the breadth and depth of NPM?
I don't know a single Lua programmer, but I can't throw a rock without hitting someone who knows JavaScript. It's something you'll pick up eventually even if you don't want to.
This statement makes zero sense. It's like someone saying Forth is silly because it doesn't have an asm.js-like layer.
Clearly you don't understand the use cases of Lua.
Lua is a convenient, easily embeddable scripting language, but that alone does not make it the best choice given how complicated the world is.
In nginx there are two places for scripting that I know of. One, to replace the somewhat awkward config stuff, like the "if" statement. Two, to enhance HTTP requests/routing a bit. I doubt people are writing long applications and I hope nginx isn't trying to become an application server.
I just can't see how a weak language like JS makes any sense for such an environment. Maybe that's why the nginx guy says he's making his own JS VM, to get it working well enough for nginx.
JavaScript might be "weak", but it's strong enough for that sort of task.
There's a lot to hate about JavaScript, but ubiquity and support is not one of those things.
You can pick up Lua in a day if you can already program, by reading Roberto Ierusalimschi's Programming in Lua.
If you've got a lot of JavaScript code, or you want to use NPM, you can't use Lua.
What does javascript have in NPM that is so awesome it isn't easily replicated and/or already existing in a lua implementation?
I honestly don't know a single NPM library I'd use that I don't know the Lua equivalent or Python equivalent or PHP equivalent. :/
> If you've got a lot of JavaScript code, or you want to use NPM, you can't use Lua.
Well, yes, if you have an existing Node.js codebase you want to port its great.
However, you made the original claim that:
"Lua has nowhere near the traction or support."
Lua is in Postgres, Redis, Nginx [already supported!]
You've got Cassandra lua implementations that try to boilerplate an API for you: https://github.com/jbochi/lua-resty-cassandra
You've got a NPM style installer in the form of luarocks: https://rocks.moonscript.org/
I really just don't understand the claim that Lua has "nowhere near the transaction or support". Is there even one cache [e.g. Redis] that supports Javascript? I can't name any.
This requires learning the new library, porting code you've already written over to the new library, testing the new code using a totally different test framework. Non-trivial.
Lua has a lot of support, don't get me wrong, but it has way, way less support than JavaScript. To say otherwise is seriously dishonest.
I am not in any way equating "support" with "superior".
This sounds like using JS just for ... technically unacquainted people to get their buzzword hit. Like XML was a while ago.
The lua support is GREAT, and make a lot of complex stuff (standard outside authentication on multiple apps) simple as using a 20 lines lua script.
Let's hope LUA doesn't fall to second class citizen.
Quite arguable. Creating a paywalled version of a FLOSS product like this has never been seen well by the FLOSS community (especial when there's been so many contributors) and has actually been subject to a lot of controversy.
https://github.com/alibaba/tengine
(though to be fair most work on new protocols seems to be from nginx itself)
Nginx Plus is a platform, not just a special version of Nginx open-source, where Nginx is a core component.
I read it as a list of hi-lights from the article, and I assume that's how he meant it to be read;
- interesting things will move to the premium version
- JS VM to power future versions
- pluggable module API comingIt may not have been meant to come across the way I objected. :)
This is the most exciting for me, as I'd much rather install from a package than have to re-compile from source.
I've figured out how to make that easier in Debian/Ubuntu: https://serversforhackers.com/compiling-third-party-modules-..., but having a command similar to Apache to enable/disable a module will be really nice.
Just tried it with Nginx 1.7.11 from release and then mainline Nginx 1.7.12 and on both I got nginx -V to output --with-http_spdy_module
But when I put in "pagespeed on (and the rest of the settings) into http { in /etc/nginx/nginx.conf
I get in /var/log/nginx/error.log: unknown directive "pagespeed" in /etc/nginx/nginx.conf:56
How is this possible?
Edit: I finally figured it out... the Nginx configuration on https://developers.google.com/speed/pagespeed/module/configu... it out of date. It's much simpler to setup spdy now. Simply add "spdy" to the nginx server config like this: listen 127.0.0.1:8082 spdy;
> I have a working prototype of a JavaScript VM that is highly optimized for NGINX’s unique requirements and we’ve begun the task of embedding it within NGINX Open Source.