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

81–90 of 131 posts

Re: Launching NginScript

#81

Post by alexbilbie »

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…

I do what you describe with no extra Nginx modules with the following line inside a location block:

  fastcgi_param X-REQUEST-ID $pid-$msec-$request_length-$remote_addr;
Using the more headers module you can also pluck things like Oauth access tokens and append them too

Re: Launching NginScript

#82

Post by dunkelheit »

CrLf wrote: post #47
stanleydrew wrote: post #22

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…

I have used ngx_lua in the past for some intelligent query rewriting and was very pleased with the experience. It is definitely great having the power of real programming language at hand and not being constrained by yet another configuration file syntax. On the other hand lua just feels very small and the temptation to fit more of the application logic into web server is low (although apparently not for others as lapis shows ;)).

I guess nginScript is mainly an outreach thing. Apparently nginx developers have decided that all those UI developers are just more comfortable writing JS than anything else. What indeed raises some red flags is that it is a subset of the language running on custom VM. So it is in fact a JS dialect which will still require some amount of learning to use it effectively (no free javascript lunch here).

Re: Launching NginScript

#83

Post by coldtea »

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.

If you think people will dump nginx for Node (which has totally different use cases) then I'm not sure how qualified the business estimation is...

Re: Launching NginScript

#84

Post by 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).

Re: Launching NginScript

#85

Post by sciurus »

CrLf wrote: post #47
stanleydrew wrote: post #22

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…

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

No, let's not call it that, because I have no idea what you mean when you say that.

Re: Launching NginScript

#86

Post by madaxe_again »

CrLf wrote: post #47
stanleydrew wrote: post #22

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…

We've written extensive partial view caching with memcached in lua in nginx, none of us having known lua when we started. It's fast as hell and the learning curve really isn't steep. Most of the tricky stuff involved the nginx api and brain-wrecking recursive and nested calls - not the language.

They're welcome to spend time building their own JS VM, it's their project - and while I don't think this is intended to appeal to the existing userbase, I think it will attract an entire new userbase, which will further nginx as a webserver and aid the goals of those who use it (faster. faster. more speed. faster. fix the bugs.) as they get more use, more paid use, and thereby more developer time.

Re: Launching NginScript

#87

Post by tootie »

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…

Firstly, I'm flattered that I sound like not a n00b :)

I should say that I haven't ever really tried this at production scale. My background is mostly consulting wherein my responsibility is to deliver a provably working solution for someone else to manage and operate. So there's my bias in this.

Other commenters have made a lot of the points I would. You can easily handle TLS in Java or JavaScript. Or you can terminate with an ELB as I usually do. A lot of load can be pushed to a CDN.

But really, I'm not convinced it would be that much slower. I know this dated, but a simple apache bench test shows Tomcat outperforming httpd for static assets [1]. I've never had a site that was remotely bottlenecked by static assets, but I've had many bugs due to obtuse mod_rewrite configs. It's cheaper to have to fewer bugs than to spin another server.

[1] http://www.devshed.com/c/a/BrainDump/Tomcat-Benchmark-Proced...

Re: Launching NginScript

#90

Post by yc1010 »

sciurus wrote: post #85
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…

"The point is to make nginx's configuration dynamic and prevent bloating applications with stuff that belongs at the (lets call it) devops level." No, let's not call it that, because I have no idea what you mean when you say that.

Some nginx configuration files are very project specific, especially when you have projects using some of the modules they offer.
Post reply on HN