31–40 of 131 posts
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'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 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-and-butter things like SSL caching. If there's a bug, you'll have a good old time debugging it's massive collection of C code. It's great, but it's not perfect.
Making nginx do custom things that you'll probably need to do in a serious environment (example: dynamically programmable SSL SNI) requires craxy mods and hacks that have only recently been made available (by third parties) and heavily reduce nginx's performance. Further, they only provide purgable proxy caching via their commercial version, which costs an exorbitant amount of money. The free purger, naturally, makes nginx lock up. I wouldn't mind chipping in a bit for nginx because I want to support their team any way, but at their current prices ($100/node/month or something like that) we simply can't afford it.
I realize this is not a popular opinion right now, but node.js is completely up to the task of running a reverse http proxy. They are basically (you likely won't notice the difference unless you're running the New York Times) competitive with nginx for performance, and as a tradeoff for an unnoticable slowdown you get a full, turing complete programming language to completely control the flow of your data. Nginx under the hood is just a reactor pattern with children that share a socket. Node.js has a cluster module that uses the exact same strategy. Mind you this is from someone that has done talks critical of reactor pattern scaling.
Also, if you have blocking I/O apps, it doesn't matter what you configure nginx to do, it's still going to lock up when someone DDoSes it with slow loris connections. Make your ruby app thread safe and use Rainbows! instead of Unicorn, or you're going to have a bad time.
I'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…
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 the worker threads.
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…
You'd rather use a dedicated load balancer like Route53 or haproxy. Don't think choosing Apache or Nginx is the right option for those really. Plus something like vert.x is very usable as a load balancer already.
>SSL Termination
Just about everything handles this already. Current best practice is to use SSL for all communication between your own servers anyway, so there's no gain. If you SSL terminate on your load balancer, these days you want to use a new SSL connection between your load balancer and application server anyway if possible.
> serving static content, caching, compression
New app servers like vert.x support Linux sendfile and handle very well for serving static content etc. Currently, nearly everyone uses Cloudflare to handle all of this anyway. No real reason to duplicate it if Cloudflare is set to handle it.
> centralized logging
Centralized logging is usually done by sending all of your logs off from each service/server to be aggregated on a dedicated box running Logstash or whatever. You don't use your reverse proxy for this?
>using different applications on the same ur space
From using the web, I don't think this is done anymore. In fact it seems to be the opposite - foo1.app.com, foo2.app.com seems to be the trend. Basically the opposite of multiple apps on 1 domain because of the big move towards microservices. Extra domains are the cheapest thing there is.
> added benefit of another layer of security
Security doesn't work that way in my experience. It's more about minimizing attack surface. If you use node and nginx and apache then any exploit that hits any of those 3 will hit you. If you only use node, then you can only get hit by exploits on node. So I'd argue it's the opposite. The more layers, the less secure.
> nginx/apache are really good at what they do
Sure, but you need to find the most efficient tool to handle your needs with the least amount of complexity. Only add something if it solves an issue that you can't solve in a simpler way just as well.
I'm curious to see the impact of this strategy on performance.
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…
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…
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…
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....
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 make use of this than make use of nginx's Lua support.
It's sad to see lua get slowly replaced by javascript.
Lua and JavaScript are very similar languages and share the basic problems. I'm indifferent.