Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launching NginScript

nginx.com

Post reply on HN
Print view View original

71–80 of 131 posts

Re: Launching NginScript

#71

Post by Dylan16807 »

n42 wrote: post #55
CrLf wrote: post #47

Earlier quoted context omitted.

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…

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…

You can consider it bloat even if you want it, which is why you want to carefully manage the size of what you add.

I wouldn't refer to JavaScript as 'overkill'; it's not more capable than Lua for scripting, it's just bigger.

Re: Launching NginScript

#72

Post by romaniv »

aikah wrote: post #21
placeybordeaux wrote: post #5

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

Well, it's a popularity contest. Lua is certainly a great language, it's fast and it works well with C. I guess that nginx team thinks that js will bring more users therefore more business. If I were to develop a product and add a scriptable layer, i'd certainly use JavaScript. Even if it is not the best language out there, it's about growing an ecosystem.

I'm willing to bet it won't bring them any new business. And in the long run, it will encourage their existing users to dump nginx and use Node.

Re: Launching NginScript

#73

Post by lohengramm »

ThinkBeat wrote: post #27
placeybordeaux wrote: post #5

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

I think is is sad to see anything replaced by Javascript. Unpopular opinion I guess. So many better choices out there.

By better choices you mean better languages or other methods of achieving the same flexibility without the complexity of a language like JS? Can you reply with examples? I am interested in alternatives to JS and LUA.

Re: Launching NginScript

#74

Post by marcosdumay »

n42 wrote: post #55
CrLf wrote: post #47

Earlier quoted context omitted.

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…

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…

> generating and adding a UUIDv4 to every request's headers

Why you can't do that in Lua?

Re: Launching NginScript

#75

Post by Rygu »

tambourine_man wrote: post #36

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.

Slightly off-topic, but I wouldn't worry. Nowadays hypervisors can boot up complete OSes in ~800ms.

https://insights.ubuntu.com/2015/05/18/lxd-crushes-kvm-in-de...

Re: Launching NginScript

#76

Post by harshreality »

TazeTSchnitzel wrote: post #24

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.

The nginx config language already is a half-assed DSL with all sorts of unintuitive limitations (chiefly caused by its insane mix of declarative and procedural elements, and arbitrary precedence of declarative directives). The last thing nginx needs is a new DSL (that everyone has to learn from scratch) with a new set of unintuitive limitations and a new set of differences from common general purpose languages.

There are plenty of good minimal languages, from embedded scheme varieties to luajit to io. If that's what you mean by a DSL (embedded minimalist scheme with some nginx-specific functions and variables, for instance) then I agree, but they chose the javascript path for a good reason: it has a healthy community and ecosystem, and while the performance won't be top notch, I don't think it'll matter.

Re: Launching NginScript

#77

Post by sangnoir »

romaniv wrote: post #72
aikah wrote: post #21

Earlier quoted context omitted.

Well, it's a popularity contest. Lua is certainly a great language, it's fast and it works well with C. I guess that nginx team thinks that js will bring more users therefore more business. If I were to develop a product and add a scriptable layer, i'd certainly use JavaScript. Even if it is not the best language out there, it's about growing an ecosystem.

I'm willing to bet it won't bring them any new business. And in the long run, it will encourage their existing users to dump nginx and use Node.

Isn't Node more of an Application server though? I don't see Node replacing Nginx in the roles it's normally used for (serving static resources, reverse-proxy). I can't think of a single upside

Re: Launching NginScript

#80

Post by marcosdumay »

wasd wrote: post #3
tootie wrote: post #2

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

He's just saying that he prefers to configure his reverse proxy in Javascript, or some other mainstream language than in the Nginx configuration language.

I can see where he's coming from. But I still slightly disagree with the feeling.

Post reply on HN