131–140 of 201 posts
Earlier quoted context omitted.
You don't need separate containers to run nginx and php-fpm.
does it involve running supervisor inside the container? that’s fine but it’s definitely not kosher. in my experience those are the ones that kick and scream when they don’t start as root.
Earlier quoted context omitted.
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,…
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.
Which sounds good in theory, until you run into issues like this: https://www.youtube.com/watch?v=tLdRBsuvVKc
TLDW: Most of the Gitlabs outage where they deleted the primary prod and backup prod database could have been solved if they just waited for the command line op to complete - but because of a lack of feedback they thought it had frozen, leading to several other plans which made the situation worse.
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?
But for API gateway or any kind of sidecars? Very valuable.
They should make a page explaining how this differs from Nginx and why it needs to be its own separate thing. I couldn’t find such a page.
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.
Earlier quoted context omitted.
In Linux where this is primarily expected to be used ASP.NET is extremely rare, as is C++ for web stuff, and Rust has a vanishingly small web presence still. Lots of people use Perl still though, if not for anything else, for legacy stuff. So might as well ask why it doesn't support Delphi.
Do you have data for your asp.net Linux claim? Feels anachronistic.
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?
Only the NGINX team would think to "simplify" loading a configuration file from the CLI by using curl to post it. smh...
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’s the advantage of server side WebAssembly over just running a Rust/whatever application?