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

121–130 of 236 posts

Re: Nginx Unit

#121

Post by ChemicalWarfare »

foo4u wrote: post #110
justonepost wrote: post #56

Earlier quoted context omitted.

microservices on their face seem cool, but in reality not so much. really, it's just SOA taken to an unnecessary extreme.

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.

Re: Nginx Unit

#122

Post by rch »

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 ?

It has the same momentum, but too much mass and not enough velocity.

Re: Nginx Unit

#123

Post by skrebbel »

floatboth wrote: post #90
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/

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.

Re: Nginx Unit

#124

Post by jimjag »

I am biased, but call me underwhelmed. It seems that with every "new" feature, nginx is copying Apache httpd, even now claiming to be the "swiss army knife" of web-servers. Embedded languages. Dynamic modules. Support of uWSGI. gracefull restarts. Thread pools... and yet people eat it up. Just goes to show what having corporate-backed marketing and PR can do.

Re: Nginx Unit

#125

Post by korzun »

FooBarWidget wrote: post #97
flachsechs wrote: post #86

Earlier quoted context omitted.

because you can work with individual microservices across clusters without a ton of overhead (or use a monolithic app server), aiding in deployment, rollback, debugging, development.

How exactly does having an app server reduce overhead, compared to running each service directly without app server? And how does having an app server compare to putting each microservice in its own Docker container and orchestrating them in Kubernetes, which is what more and more companies seem to be doing?

You would be able to merge your services under a single server and have them talk to each other internally sans latency overhead. It also allows you to easily scale up and down and segment things on demand.

Re: Nginx Unit

#126

Post by user5994461 »

agentgt wrote: post #112

I'm still not sure I understand "Unit". I can't speak for the other languages (PHP, Go, Python) but I have some reservations about it helping Java (as well as Erlang and other (J)VM languages) as FastCGI like stuff has been attempted for Java in the past with not very good success with the exception of Resin. I guess it would be interesting though if they did a native Servlet 3.0+ implementation like Resin but I doub…

CGI for PHP/Python.

AJP/mod_jk for Java.

Re: Nginx Unit

#127

Post by korzun »

jimjag wrote: post #124

I am biased, but call me underwhelmed. It seems that with every "new" feature, nginx is copying Apache httpd, even now claiming to be the "swiss army knife" of web-servers. Embedded languages. Dynamic modules. Support of uWSGI. gracefull restarts. Thread pools... and yet people eat it up. Just goes to show what having corporate-backed marketing and PR can do.

I don't understand why people want to write something off without even trying it.

This is not'nginx'. You can't sit and write this off because Apache did something similar ten years ago. The build in API alone is worth exploring.

Re: Nginx Unit

#128

Post by bkeroack »

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.

Re: Nginx Unit

#129

Post by Prefinem »

jimjag wrote: post #124

I am biased, but call me underwhelmed. It seems that with every "new" feature, nginx is copying Apache httpd, even now claiming to be the "swiss army knife" of web-servers. Embedded languages. Dynamic modules. Support of uWSGI. gracefull restarts. Thread pools... and yet people eat it up. Just goes to show what having corporate-backed marketing and PR can do.

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.

Re: Nginx Unit

#130

Post by korzun »

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…

Technically, you can expose the Unit API within an internal network.
Post reply on HN