Could 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 PHP applications, or use a separate init system like systemd to run Go or Node applications. Now NGINX would assume those responsibilities and provide you with a consistent interface.
Here you can see the configuration of workers and user/group permissions for a Go application:
That's how my reading of it goes. You provide an "endpoint" for the library to call, configure the Unit framework, and their Manager connects the nginx frontend to that Unit framework.
No real idea if it does so using fcgi or some other socket-based proxying, or if the unit is spun up as a separate process and handed the raw socket and some shared memory after the headers are parsed (closer to how mod_php works).
Yes, you can generally think of it as a replacement for mod_php as Unit would parse requests from NGINX, pass them along to the PHP parser, then return the responses back to NGINX. That's the same job mod_php does for Apache and what PHP-FPM (essentially) does for servers like NGINX.
Upon first reading I thought that Unit needed to be behind NGINX to function. When actually it listens for requests as a separate server, entirely. It only provides an API for configuration purposes.
However, If you want to use the other features of NGINX, like providing static files, you will need to put it in front of Unit.
