Nginx Unit
101–110 of 236 posts
Re: Nginx Unit
#102So it looks like they basically rewrote uwsgi and slapped a rest api on top of it.. (as a big fan of uwsgi, that seems like a reasonable thing to do...)
Re: Nginx Unit
#103Earlier quoted context omitted.
When was the last time you heard something about zlib? At a certain point - libraries are basically done. They are widely distributed, everyone knows what they are, there is no reason to talk about them but they are still maintained and heavily used.
Libraries can be done, but that has got nothing to do with momentum. Momentum depends on mindshare, on the willingness of people to use and to keep using it. Most programmers don't choose technology based purely on merits, they choose it based on "I heard X talk about Y and s/he said good things, so I guess I'll use it". We programmers aren't as rational as we think.
Re: Nginx Unit
#104Re: Nginx Unit
#105Could anyone explain to me why I would want to use this? What exactly is the use case and benefits of it when I am for example running a go web application?
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…
Is it like the apache mod_php for php for example ?
Thanks in advance for your answer
Re: Nginx Unit
#106I am surprised noone mentioned Kong [1] yet. It seems to implement most of stuff promised by Unit and it was around for a few years. [1] https://getkong.org/
Re: Nginx Unit
#107I 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: Nginx Unit
#108Earlier 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?
Re: Nginx Unit
#109I am surprised noone mentioned Kong [1] yet. It seems to implement most of stuff promised by Unit and it was around for a few years. [1] https://getkong.org/
Kong is just an API gateway: you run your own infrastructure as usually and put a gateway on top of it.
Re: Nginx Unit
#110This 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/
microservices on their face seem cool, but in reality not so much. really, it's just SOA taken to an unnecessary extreme.