Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nginx Unit – Universal web app server

github.com

Post reply on HN
Print view View original

61–70 of 201 posts

Re: Nginx Unit – Universal web app server

#61

Post by fideloper »

I was just playing with this the other day.

Trying to find context on what it was, I saw it’s been on HN a few times (mostly to the sound of people asking the same question).

Since I mostly do php/laravel, I was pleasantly surprised that it let me remove php-fpm from my stack - extremely nice when putting PHP apps in a container.

I personally have come to dislike PHP-FPM’s max_children and similar settings, whose low defaults come as an annoying surprise when you suddenly get gateway errors before your server is even overloaded. (and having to add nginx AND php-fpm “layers” into a container to run PHP apps is all sorts of annoying).

Unit doesn’t have as many features as Nginx so I suspect it’s best used when there’s another fully-featured http layer in front of Unit (to more easily handle TLS, protecting dot files, gzip, cache headers, and the like).

Overall i’m excited to use it when making images for php apps.

Re: Nginx Unit – Universal web app server

#62

Post by pacifika »

DarkCrusader2 wrote: post #60

> open source server project that works as a reverse proxy, serves static assets, and runs applications in multiple languages. Isn't this what Nginx also does. How is Nginx Unit different beyond configuration via JSON REST APIs? The Github readme or their site is not very clear on this.

Nginx doesn’t talk to Python or php directly it’s talks to the application server.

Re: Nginx Unit – Universal web app server

#63

Post by Matl »

lagniappe wrote: post #49

I built something like this, but with much simpler syntax and automatic https simply bc I'm not smart enough to reliably set up server blocks and letsencrypt every time I route a new app. AppServe takes care of all that, and even if I did know the syntax by heart to do it in nginx, this is still faster. https://github.com/donuts-are-good/appserve

Nice, that being said if the concern is complex config, there's always Caddy[1].

1 - https://github.com/caddyserver/caddy

Re: Nginx Unit – Universal web app server

#64

Post by tyingq »

crvdgc wrote: post #41
jiggawatts wrote: post #37

This seems a lot more like how IIS works, unless I'm missing something? As an aside: it's always curious to see how the programming world has splintered into cliques that no longer hang out together. NGINX Unit is a "Universal" web server without support for C++, Rust, or ASP.NET! But PERL is supported, like the 1990s Linux cgi-bin world never went away.

Don't know about ASP.NET, but one of the supported languages is assembly, so I'd presume C++ and Rust can easily add a wrapper around that. > Binary-compiled languages in general: using the embedded libunit library. From https://unit.nginx.org/keyfeatures/#supported-app-languages

Reads like it's not real straightforward or well documented for rust:

https://github.com/nginx/unit/issues/738

Re: Nginx Unit – Universal web app server

#65

Post by Nullabillity »

chrismorgan wrote: post #34
mindwok wrote: post #11

Well I commend the Nginx team for trying something new and launching this, even though I'm not sure what I would use it for personally. Slightly tangental, but it always irks me when I see these kinds of responses in JSON: { "success": "Reconfiguration done." } Really this should be something like "result": "success". Using "success" as a key name tells me nothing about the data it's representing.

In this particular example, it’s actually a whole lot worse than that, by spec at least. Excerpt from their OpenAPI schema https://github.com/nginx/unit/blob/7dd5ad93a4c147b086a8d82ec... >: jsonSuccessMessage: type: object description: "JSON message on success." additionalProperties: type: string jsonErrorMessage: type: object description: "JSON message on error." additionalProperties: type: string Yes, this is as ba…

By Serde's classification, `success: {}` is a textbook externally tagged representation.

Re: Nginx Unit – Universal web app server

#66

Post by loloquwowndueo »

pydry wrote: post #51
eterps wrote: post #43

Earlier quoted context omitted.

Eric S. Raymond, in his guide "The Art of Unix Programming", mentions this principle as Rule of Silence: "When a program has nothing surprising to say, it should say nothing." His statement probably related to command line applications, but it makes sense for a lot of cases.

It sounds smart but what counts as surprising is entirely context dependent and most programs won't be aware of your context. E.g. a command line app where you put a subtly wrong switch in that does exactly what it thought you wanted and prints nothing while outputting a 0 exit code is dangerous.

What, like rm -rf ?

Re: Nginx Unit – Universal web app server

#67

Post by donatj »

I remember when they announced this a couple years ago I had no idea why I would use it over standard nginx. That seems to still be the case.

It’s JSON controlled via Curl? And has a bunch of langue’s built in for some reason? The question becomes why?

Re: Nginx Unit – Universal web app server

#68

Post by lagniappe »

Matl wrote: post #63
lagniappe wrote: post #49

I built something like this, but with much simpler syntax and automatic https simply bc I'm not smart enough to reliably set up server blocks and letsencrypt every time I route a new app. AppServe takes care of all that, and even if I did know the syntax by heart to do it in nginx, this is still faster. https://github.com/donuts-are-good/appserve

Nice, that being said if the concern is complex config, there's always Caddy[1]. 1 - https://github.com/caddyserver/caddy

AppServe gets compared to Caddy a lot, which is very flattering, so thank you :) Caddy's good stuff!

Re: Nginx Unit – Universal web app server

#70

Post by thibaut_barrere »

chrismorgan wrote: post #34
mindwok wrote: post #11

Well I commend the Nginx team for trying something new and launching this, even though I'm not sure what I would use it for personally. Slightly tangental, but it always irks me when I see these kinds of responses in JSON: { "success": "Reconfiguration done." } Really this should be something like "result": "success". Using "success" as a key name tells me nothing about the data it's representing.

In this particular example, it’s actually a whole lot worse than that, by spec at least. Excerpt from their OpenAPI schema https://github.com/nginx/unit/blob/7dd5ad93a4c147b086a8d82ec... >: jsonSuccessMessage: type: object description: "JSON message on success." additionalProperties: type: string jsonErrorMessage: type: object description: "JSON message on error." additionalProperties: type: string Yes, this is as ba…

> Yes, this is as bad as it looks: “success” isn’t even part of the schema. It’s in the examples, but not the actual schema definition.

Having gone through a pretty heavy overhaul of an "OpenAPI" (full code in Elixir at https://github.com/etalab/transport-site/pull/3351), I stumbled on that exact type of problem!

At the scale of nginx, having automatic verification that the examples (and the output of the API in general) match the specification would be great.

At our scale, here is what really helped me go through the rework (and ensure we do not regress too easily):

- setting additionalProperties to "false" to detect key field "rot"

- using "required: [x,y,z]" on everything, and by default specify "all the property keys", with an opt-out (so that each time a developer adds a field later, it is considered mandatory, unless otherwise specified)

- use tooling during the tests: "assert_schema" (with OpenAPISpex) to ensure our API endpoints responses pass the spec (additionalProperties: false helps ensure we get an exception in case of key field rot, again!)

- even more useful: crawl our production most important endpoints and tweak the spec until everything is green (an example of useful use of Task.async_stream in Elixir, by the way) https://github.com/etalab/transport-site/pull/3351/files#dif...

It can be super frustrating for users to live with the uncertainty of the response of an API for sure, and I was happy to discover the Elixir tooling (OpenAPISpex in particular) worked so nicely once I understood what I had to do.

Post reply on HN