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

Nginx Unit

nginx.com

Post reply on HN
Print view View original

181–190 of 236 posts

Re: Nginx Unit

#181

Post by nly »

goblin89 wrote: post #168
skrebbel wrote: post #123

Earlier quoted context omitted.

I thought it was because there's a lot about http that's overhead and/or tough to get right, which can then be delegated to the server. Also, websockets actually map pretty badly to http, conceptually, and fit zeromq much better IMO.

Regarding websockets (admittedly off-topic re Mongrel though), I recently found out about Pushpin[0], which seems to be an elegant way to translate WS into HTTP, should it be of interest to someone. Basically a proxy-server that takes care of accepting either websockets or HTTP on the front, and talking only HTTP on the other side. [0] http://pushpin.org

I evaluated PushPin for a project recently but ended up going with Nchan

https://nchan.io/

Re: Nginx Unit

#182

Post by a-kojeve »

bkeroack wrote: post #154
wyc wrote: post #150

Earlier quoted context omitted.

Pushing back on this a bit...for example, securely exposing a JSON endpoint to the public internet requires extra machinery that applications like nginx bring for free. If you simply set the router to your handler, then you accept arbitrarily large request sizes, wide open for DoS attacks. You have to either manually add limits or pull in some library. nginx caps these by default. Want throttling or load balancing? A…

I would argue that all is part of security-aware software engineering. If you aren't thinking of these things you have no business writing publicly-exposed HTTP applications.

What if I have an application that needs to be deployed internally and externally in separate instances. Identical application, but different security contexts. Using Nginx to handle these concerns is easy.

Re: Nginx Unit

#183

Post by Ruud-v-A »

bkeroack wrote: post #128

It's worth noting that it's rarely necessary or desirable to put an app server like nginx in front of Go HTTP server applications. The Go standard library http and TLS stack are production quality and rock solid. Putting something in front is mostly cargo culting from people more used to the worlds of PHP/Python/Ruby/etc.

I love Warp for Haskell, but I would still be hesitant to expose it directly. It’s simply not used as much as Nginx or Apache. Less people have spent time trying to break it.

Re: Nginx Unit

#184

Post by uvtc »

pilif wrote: post #27

> It is not recommended to expose unsecure Unit API why do people always use "not recommended" when they actually mean "do not ever do this or you'll end up the laughing stock in the tech press" Exposing this otherwise awesome API to the public will amount to a free RCE for everybody. So not ever expose this to the public, not even behind some authentication. It's very cool that by design it's only listening on a dom…

> why do people always use "not recommended" when they actually mean "do not ever do this or you'll end up the laughing stock in the tech press"

For the same reason they say, "non-trivial" when they really mean "nearly impossibly difficult". :)

Re: Nginx Unit

#185

Post by donalhunt »

a-kojeve wrote: post #182
bkeroack wrote: post #154

Earlier quoted context omitted.

I would argue that all is part of security-aware software engineering. If you aren't thinking of these things you have no business writing publicly-exposed HTTP applications.

What if I have an application that needs to be deployed internally and externally in separate instances. Identical application, but different security contexts. Using Nginx to handle these concerns is easy.

It's a common myth that internal networks are a more secure environment. You are better off implementing the philosophy behind something like Google's BeyondCorp¹ effort.

¹ https://cloud.google.com/beyondcorp

Re: Nginx Unit

#186

Post by zzzcpan »

derefr wrote: post #179
zzzcpan wrote: post #134

Earlier quoted context omitted.

Because people have a hard time figuring out what it is. Could you explain what it is? What benefits does it have to make it worth exploring? To me it looks like a rather invasive but flexible and dynamically configurable inetd. But it forces you to use its own libraries to receive http requests.

It's a lot like OpenResty ( https://openresty.org/en/ ), which is Nginx with a Lua interpreter embedded and bridged to its request-response cycle (the OpenResty page explains the point of that pretty well); but instead of Lua, Unit has a bunch of other language runtimes embedded.

I haven't found any embedded interpreters or runtimes here. Quite the opposite, I see they have libraries they ship with other languages that a user has to use in order to receive http requests.

Re: Nginx Unit

#187

Post by Vendan »

marktangotango wrote: post #166
ekimekim wrote: post #146

Earlier quoted context omitted.

Minor quibble, in the context of serving static files (ie. from disk), go doesn't use async I/O, the file I/O blocks the thread until it's complete. But since go's scheduler is M:N this doesn't lock up the whole program, so your point stands.

I would be surprised if go did not use the 'sendfile' syscall that does exactly this, is there a go nut that can clarify?

Go does shortcircuit to sendfile where possible.

Re: Nginx Unit

#188

Post by VT_Drew »

overcast wrote: post #132
Prefinem wrote: post #129

Earlier quoted context omitted.

When I started with apache, I thought it was great, but after moving to nginx, the speed and simplicity made me never look back. While these new features to nginx aren't new to the world, they are a nice welcome addition to a system that IMO is far superior to apache.

I never found Nginx especially simple to setup, the config files were always messy. Caddy seems to have knocked this out of the park for me, especially considering automated https, and redirection.

>the config files were always messy.

How? It so much cleaner and simpler than Apache. I don't get this sentiment.

Re: Nginx Unit

#189

Post by jkarneges »

nly wrote: post #180
jkarneges wrote: post #171

Earlier quoted context omitted.

Pushpin uses Mongrel2 under the hood to handle incoming WebSocket connections, so not entirely off topic. :) It's pulled in as a dependency and launched in the background.

I thought PushPin was based on Qt?

It's multi-process. The core logic is a Qt application, but it delegates the external protocol I/O to separate processes. Mongrel2 handles inbound and Zurl handles outbound (Zurl is a project of ours that is basically the inverse of Mongrel2).

Re: Nginx Unit

#190

Post by msimpson »

Xoros wrote: post #105
msimpson wrote: post #87

Earlier quoted context omitted.

NGINX allows you to proxy a back-end applications giving you the ability to load balance, handle upstream failures with custom maintenance pages, employ server blocks (virtual hosts), and much more. However, you always need to do the leg work to get your specific application language up and running. This new unit system makes that job easier as you would no longer need to employ separate middleware, like PHP-FPM for…

I'm sorry but I'm not sure I get it. Is it like the apache mod_php for php for example ? Thanks in advance for your answer

Yes, you can generally think of it as a replacement for mod_php as Unit would parse requests from NGINX, pass them along to the PHP parser, then return the responses back to NGINX. That's the same job mod_php does for Apache and what PHP-FPM (essentially) does for servers like NGINX.

You can see the PHP configuration here:

http://unit.nginx.org/docs-configuration.html#php-applicatio...

And here's the configuration needed to integrate Unit with NGINX:

http://unit.nginx.org/docs-integration-with-nginx.html

Post reply on HN