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

161–170 of 236 posts

Re: Nginx Unit

#161

Post by DandyDev »

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.

Or... you spend your time building something useful, leveraging skills you do have, and let nginx leverage its own strengths.

What you say, sounds like NIH syndrome to me.

Re: Nginx Unit

#163

Post by dasil003 »

ChemicalWarfare wrote: post #121
foo4u wrote: post #110

Earlier quoted context omitted.

It's really SOA without the XML based service bus.

You can definitely do microservices that way but in reality they tend to be more granular both functionality wise and density-wise. With old skool SOA you'd typically have a monolith app with a bunch of endpoints. With microservices, especially in a containerized environment they tend to be more lightweight.

Microservices is just SOA rebranded for the cool kids. The fact that modern orchestration and tooling makes it easier to have more granular services changes the equation for how you factor the services, to be sure, but it's an evolution not a revolution.

Re: Nginx Unit

#164

Post by bkeroack »

DandyDev wrote: post #161
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.

Or... you spend your time building something useful, leveraging skills you do have, and let nginx leverage its own strengths. What you say, sounds like NIH syndrome to me.

Secure software isn't useful? Insecure software isn't eventually value-destroying?

Really what this sub-thread is arguing is that security Isn't My Job(TM) as application developer. I disagree. Furthermore telling app devs not to worry about it because nginx takes care of everything is a false security blanket that will bite you eventually.

Not accepting unbound input and sane rate-limiting are kind of basic stuff, no? I'm not saying every app developer needs to be a Defcon wizard, just that they should have some fundamental awareness of secure coding standards for web apps if that's what they're building.

Re: Nginx Unit

#165

Post by tlb »

agnivade wrote: post #42
skrebbel wrote: post #24

This looks pretty cool, and makes me sad that Mongrel2 never became popular. In short: Mongrel2 solves the same problem, but does it by letting your application handle requests and websocket connections over ZeroMQ instead of eg FastCGI. I guess it lost momentum when ZeroMQ did. Anyone know why? Sounds like a dream solution in the current microservice hype. http://mongrel2.org/

Wait, zeromq lost momentum ? When did that happen ?

I recently switched from zeromq to straight libuv sockets with jsonl (\n-separated json) payloads. Because I'm working inside a Node process, combining zmq's threading model with Node's threading model was a pain. Now, there's a single IO thread which is the same as the Javascript engine thread, and I can use uv_work to run CPU-intensive tasks on multiple cores.

Re: Nginx Unit

#166

Post by marktangotango »

ekimekim wrote: post #146
vertex-four wrote: post #138

Earlier quoted context omitted.

Go I/O is async by default, I figured, so... It could be that nginx is more efficient at static file serving, but that'd be down to being specifically designed and optimised for it rather than some "sync vs async" thing.

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?

Re: Nginx Unit

#167

Post by sixdimensional »

agnivade wrote: post #42
skrebbel wrote: post #24

This looks pretty cool, and makes me sad that Mongrel2 never became popular. In short: Mongrel2 solves the same problem, but does it by letting your application handle requests and websocket connections over ZeroMQ instead of eg FastCGI. I guess it lost momentum when ZeroMQ did. Anyone know why? Sounds like a dream solution in the current microservice hype. http://mongrel2.org/

Wait, zeromq lost momentum ? When did that happen ?

Unfortunately, the founder of ZeroMQ, Pieter Hintjens passed away (due to cancer) [1]. He was a regular on HN [2].

ZeroMQ still works great and the open source community is still maintaining it on GitHub [3]. I just think people are also looking at other technologies. A lot of interest popped up in things like Apache Kafka and Samsa. I still think ZeroMQ holds a unique place due to its lightweight and simple nature.

[1] https://news.ycombinator.com/item?id=11547212

[2] https://news.ycombinator.com/user?id=PieterH

[3] https://github.com/zeromq

Re: Nginx Unit

#168

Post by goblin89 »

skrebbel wrote: post #123
floatboth wrote: post #90

Earlier quoted context omitted.

Yeah, Mongrel2 looked like a good idea… but turns out it's kinda pointless. Why talk to your app via HTTP-reencoded-as-ZMQ when you can just talk straight up HTTP? Pretty much all languages have very fast and concurrent HTTP servers these days.

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

Re: Nginx Unit

#169

Post by yumyumyumyumyum »

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.

And yet this issue remains unsolved: https://github.com/golang/go/issues/16100

Your choice is force a timeout and kill streaming requests, but defend against slow client DOS, or support streaming requests and suffer from a trivial slow client DOS.

For this and other reasons I still recommend fronting golang with something more capable on this front.

Re: Nginx Unit

#170

Post by stanleydrew »

bkeroack wrote: post #164
DandyDev wrote: post #161

Earlier quoted context omitted.

Or... you spend your time building something useful, leveraging skills you do have, and let nginx leverage its own strengths. What you say, sounds like NIH syndrome to me.

Secure software isn't useful? Insecure software isn't eventually value-destroying? Really what this sub-thread is arguing is that security Isn't My Job(TM) as application developer. I disagree. Furthermore telling app devs not to worry about it because nginx takes care of everything is a false security blanket that will bite you eventually. Not accepting unbound input and sane rate-limiting are kind of basic stuff, n…

> Secure software isn't useful?

Nowhere in the sub-thread is this claimed.

> Insecure software isn't eventually value-destroying?

Nowhere in this sub-thread is anyone suggesting otherwise.

> Furthermore telling app devs not to worry about it because nginx takes care of everything is a false security blanket that will bite you eventually.

Nobody said this. But while we're on the topic the more likely false security blanket comes from telling app devs "just use 'net/http' and 'crypto/tls' and everything will be fine without a reverse proxy."

In any case the straw men you've raised are distracting and not driving the conversation forward.

Post reply on HN