Live data from Hacker News

Nginx Unit – Universal web app server

github.com

31–40 of 201 posts

Re: Nginx Unit – Universal web app server

#31
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.

Heh. My pet peeve are useless success fields. A 200 response tells you it was successful already. We can talk about a „message“ field or something if you intend to display it to a user, but even that should be implicit by being a response to a specific request. If I send a POST /configuration, is there really something new to be gained from that message that the client cannot figure out on its own? Wouldn’t, perhaps, a 201 No Content suffice?

Re: Nginx Unit – Universal web app server

#32
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.

Unit has been around for half a decade. It feels like an evolution to something like Phusion Passenger, but it's not quite cloud-native. A lot of the documentation is tailored to installing directly on a server and some essentials (i.e. prometheus metrics) are missing.

I briefly evaluated it for bringing a PHP team into our Kubernetes cluster, but then ended up writing a bit of Go code to proxy into a real nginx+fcgi while adding a syslog sink (so PHP could log to stdout/stderr) and our standard prometheus metrics on the Go http server.

Re: Nginx Unit – Universal web app server

#34
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 bad as it looks: “success” isn’t even part of the schema. It’s in the examples, but not the actual schema definition. The way success or failure is actually indicated is by HTTP status codes. 200 is success, 400/404/500 is error. So, they seem to set very bad precedent in at least one of their response and their schema.

But I was expecting it to be something like {"success": string} | {"error": string}, which is frankly a perfectly reasonable way of doing things: an untagged, but still unambiguous, union. It can make for quite pleasant code, too: `if response.success` and such.

You’re looking for a tagged union, something like {"result": "success" | "error", "message": string} (or alternatively like {"result": "success", "message": string} | {"result": "error", "code": string, …}), which is also a perfectly reasonable way of doing things. In some ways it can be viewed as more principled, as it more formally allows you to check the tag.

Really, the two approaches are much of a muchness. They each have their strengths and their weaknesses. But if general status is being done at the HTTP layer, I’d prefer {"message": "Reconfiguration done."}, or… well, actually, just a 204 No Content response, and no JSON or body at all.

(On the terms untagged and tagged unions as I’m using them: they’re necessarily a bit different from the concepts as exposed in languages like C, since you’re dealing with a model built on objects rather than bytes, but they’re still reasonable descriptions of them. In Serde’s classifications, they’d be the untagged and internally tagged enum representations https://serde.rs/enum-representations.html>.)

Re: Nginx Unit – Universal web app server

#35
post #24

Earlier quoted context omitted.

> a simple docker-compose Abstraction at it's finest.

What strikes you as difficult with compose files? In fact, I would say it’s the most concise format to describe a desired state of running applications currently available.

Nothing is difficult about them, compose is easy enough that you can grok it in a day.

You saw the lament in my comment though and that speaks a deeper truth.

If WSL took off quick enough we could have had lxc as the main player rather than the bastardisation of lxc that is docker.com

For an open source project they make it incredibly hard to access what are essentially text files for containerisation setups on windows or mac?

https://github.com/docker/hub-feedback/issues/1103

Re: Nginx Unit – Universal web app server

#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.

Re: Nginx Unit – Universal web app server

#38
post #30

This is really great! What I'm really look forward to trying is the server side WebAssembly: https://unit.nginx.org/configuration/#configuration-wasm . Huge potential!

What specifically are you looking forward to?

I've been tinkering quite a bit with WasmCloud and WasmEdge lately, for some data workloads (scraping, ingesting, apis etc) mainly as an excuse to learn WebAssembly.

What I want to see for myself is how Unit compares to those for this reduced scope (api's/services) and how fast I can be productive with it. This could be a good starting point for a lot of new applications, kind of an "airflow (the data orchestration thing) on Webassembly".

So main points are performance (is it good enough) and developer experience (is it easy to maintain/change).

Nothing really ground breaking, just trying out stuff.

Re: Nginx Unit – Universal web app server

#39
post #6

I only glanced at the docs, but way they expect apps to integrate with it seems a bit convoluted to me? It's not really a reverse proxy at this What would be wrong with just using HTTP/2, maybe with a few custom headers sprinkled in for custom features?

> It's not really a reverse proxy at this

In fact it's not one at all, nor does it claim to be. It's an app server.

Re: Nginx Unit – Universal web app server

#40
Hey, this is pretty cool to see!

Here's a page with the features: https://unit.nginx.org/keyfeatures/

The languages supported, if anyone is curious:

  Binary-compiled languages in general: using the embedded libunit library.
  Go: by overriding the http module.
  JavaScript (Node.js): by automatically overloading the http and websocket modules.
  Java: by using the Servlet Specification 3.1 and WebSocket APIs.
  Perl: by using PSGI.
  PHP: by using a custom SAPI module.
  Python: by using WSGI or ASGI with WebSocket support.
  Ruby: by using the Rack API.
  WebAssembly: by using Wasmtime.
I'm currently using Apache as a reverse proxy for most apps and sometimes PHP-FPM when I need to run software with PHP, which works well for my personal needs (mod_md and mod_auth_openidc are pretty cool), but it's cool to see something similarly interesting to OpenResty coming along as well, too!
Post reply on HN