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

91–100 of 201 posts

Re: Nginx Unit – Universal web app server

#91

Post by FridgeSeal »

tecleandor wrote: post #74
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.

That's like when I see APIs that give you responses with a 200 code, but then in the message there's a backend error.

Looks pointedly at graphQL projects.

Re: Nginx Unit – Universal web app server

#92

Post by sneak »

gibmeat wrote: post #90

Why the obsession (it seems to be the prominent point in the readme) with configuration via API? How often do you need to add php support on the fly? I want to configure my app server via files so it just starts up in the state that I expect. What am I missing?

This allows you to start up generic machines with no configuration and customize them after boot from a remote host.

It's not so much "on the fly", as it is moving the long-term config storage to a different system.

Re: Nginx Unit – Universal web app server

#93

Post by Ayesh »

gibmeat wrote: post #90

Why the obsession (it seems to be the prominent point in the readme) with configuration via API? How often do you need to add php support on the fly? I want to configure my app server via files so it just starts up in the state that I expect. What am I missing?

Probably the most common use case is SaaS providers that support custom domain name for whatever the software it is. For example, a site uptime monitoring service might offer a feature to host a status page on a custom (sub)domain of the customer. The SaaS now needs to programatically create virtual hosts on demand, issue HTTPS certificates, run routine updates, etc.

An API and a web server with small segmented updates make this so much easier. Compare this to Apache, that has to wait to properly end existing connections before reloading, has a config file parsing overhead, and probably does not scale that well with several virtual hosts anyway. There are hardware/File System level limitations as well.

Re: Nginx Unit – Universal web app server

#94

Post by cxcorp »

TheHappyOddish wrote: post #39
spoiler wrote: 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.

> NGINX Unit – universal web app server – a lightweight and versatile open source server project that works as a reverse proxy, serves static assets, and runs applications in multiple languages.

https://github.com/nginx/unit

Re: Nginx Unit – Universal web app server

#96

Post by rascul »

johnchristopher wrote: post #77
coldtea wrote: post #58

Earlier quoted context omitted.

YAML is an order of magnitude more hell...

But TOML is worse, right ? I can't write nor read TOML to save my life... :(

TOML is much simpler in general but it does have its warts. It's basically just key = "value" pairs in [sections] for the simple stuff.

Re: Nginx Unit – Universal web app server

#98

Post by tough »

thibaut_barrere wrote: post #70
chrismorgan wrote: post #34

Earlier quoted context omitted.

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 gen…

I recently found this open source postman typed alternative, hadn't had time to really try it yet but the types stuff should help here no?

https://recipeui.com/

Re: Nginx Unit – Universal web app server

#99

Post by revskill »

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.

Should it be

{ status: 200, body: { "message": "Reconfiguration done." } }

?

Re: Nginx Unit – Universal web app server

#100

Post by segfaltnh »

notpushkin wrote: post #25
Grimburger wrote: post #4

Earlier quoted context omitted.

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

Unironically this. After trying Kubernetes, Terraform, Ansible, and various proprietary PaaS config formats, I've grown to love Compose files' simplicity.

Yes, when compared to extreme complexity, compose is simpler. But it's hardly simple.
Post reply on HN