So does it use fastcgi to rule them all?
Nginx Unit
151–160 of 236 posts
Re: Nginx Unit
#152Earlier 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.
I share your love for Caddy, but having worked with all three, I do agree that nginx is easier than Apache. The config file isn't perfect, but I wouldn't call it messy, and I prefer it's syntax httpd's. But to each their own.
Re: Nginx Unit
#153I 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.
Performance is a feature.
Re: Nginx Unit
#154It'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.
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.
Re: Nginx Unit
#155This 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/
That is a really cool idea, do you know of other projects like it?
Nginx Unit? :-)
Re: Nginx Unit
#156Re: Nginx Unit
#157This 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 ?
When the main developer decided that it wasn't good enough and started working on nanomsg (http://nanomsg.org/)
Re: Nginx Unit
#158Sounds like uWSGI based on the description. I wonder how it'll play along with certain environments like Kubernetes.
Same. I really want to like (and use) uWSGI, for many reasons, but I find it's lacking severely in the department of documentation (searching "uwsgi" on Amazon gives zero hits!). A properly edited book would be awesome. I would pay for it of course.
>Same. I really want to like (and use) uWSGI, for many reasons, but I find it's lacking severely in the department of documentation (searching "uwsgi" on Amazon gives zero hits!).
Agreed. After recently testing out Python for a web dev project I was really dismayed at the fragmentation and lack of usability in the landscape of application servers. Here's hoping this might lead to some standardization.
Re: Nginx Unit
#159Oh, they wrote their own uwsgi, based on what presumably started as nginx2. That's cool.
I hope they would avoid the Second System syndrome..
Re: Nginx Unit
#160I initially thought it would allow to dynamically handle upstreams list (and other configuration) like hipache is doing [1], which would be awesome for dokku or other container management systems which rely on system nginx. But after seeing languages mentioned, I'm confused. Is it supposed to replace language specific servers, like unicorn and puma for rails (but then, I'm confused about what such kind of support wou…
Re the Go thing: they give you a go package: https://github.com/nginx/unit/tree/master/src/go/unit.
Note that it's actually CGo (which is not Go), and it uses a non-standard build process to install it: http://unit.nginx.org/docs-installation.html#source-code.
I don't like it at all :( I usually put plain nginx in front of my app, to handle static files and simple load-balancing, but this seems to be oriented towards handling issues best handled elsewhere.