Live data from Hacker News

Nginx Unit

nginx.com

31–40 of 236 posts

Re: Nginx Unit

#31

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/

Mongrel2 was indeed a nice idea on paper.

It never had much momentum though -- but what it lost and killed it was Zed's interest.

Re: Nginx Unit

#32

I'm having a hard time seeing what niche this fills. It seems to be both a process manager and TCP proxy. What am I missing here? What makes this better than, for example, using docker-compose? I think a "how it works" or "design doc" would be really helpful. That said, the source files do make for pleasant reading. The nginx team has always set a strong example for what good C programming looks like. EDIT: Their blo…

>What makes this better than, for example, using docker-compose?

Not having to use docker would be a huge plus for me.

Re: Nginx Unit

#34

[honest question, not being negative] what real use-case is not already being addressed by existing technologies?

For almost every new product you see, the answer is: none.

It's not about making something impossible possible. It's about improving possible things in some dimension - like speed, safety, flexibility, or - in this case - standardization and integration with already used tool.

Re: Nginx Unit

#35

[honest question, not being negative] what real use-case is not already being addressed by existing technologies?

Honest question, not being snarky: when did the existence of other products handling the same use-cases ever stopped people from creating another?

For one, it's not just "handling a use-case" it's also _how_ you handle it. And within what ecosystem you handle it. And what kind of support etc you offer with it. Etc...

Re: Nginx Unit

#36
post #6

Looks to be a good candidate to replace omnipresent nginx based API routers

I have a small flask application which basically is a rest get post API server. I'm struggling to make deployment easy. With PHP, i just push to the application server and rsync that folder into var www html for Apache httpd but what would I do for flask python 3?

You can run gunicorn (that loads your flask app) as a service using systemd on e.g. port 9000 and then have nginx (also run as a systemd service) proxy port 80 traffic to that port and handle static files etc.

Re: Nginx Unit

#37
I'm happy to see this. nginx itself is excellent software, I'll be happy to use similar tech for the application server as well (instead of uwsgi).

There are a couple of options I'd like to see added to the Python configuration though before I could try it:

- Ability to point it at a virtualenv.

- Ability to set environment variables for the application.

Re: Nginx Unit

#38
post #6

Looks to be a good candidate to replace omnipresent nginx based API routers

I have a small flask application which basically is a rest get post API server. I'm struggling to make deployment easy. With PHP, i just push to the application server and rsync that folder into var www html for Apache httpd but what would I do for flask python 3?

As with most things, there is more than one way to do it. Push to the application server and hook it to your flask application using [uWSGI](http://flask.pocoo.org/docs/0.12/deploying/uwsgi/), for example.

[Here's](https://www.digitalocean.com/community/tutorials/how-to-serv...) an old guide for running Flask with uWSGI and nginx on Ubuntu. There are several more recent, detailed instructions online.

Personally, I have an AWS instance running a Node.JS server on (blocked) port 8000, a Django uWSGI app on 8001, and a static resume site, all being reverse-proxy served by nginx. So I don't really see the advantages of Nginx Unit yet.

Re: Nginx Unit

#40

[honest question, not being negative] what real use-case is not already being addressed by existing technologies?

For almost every new product you see, the answer is: none. It's not about making something impossible possible. It's about improving possible things in some dimension - like speed, safety, flexibility, or - in this case - standardization and integration with already used tool.

Great answer! I wondered about this myself for a moment :)
Post reply on HN