Live data from Hacker News

Nginx Unit – Universal web app server

github.com

161–170 of 201 posts

Re: Nginx Unit – Universal web app server

#161
post #143

Earlier quoted context omitted.

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

Compose is an open source project entirely separate to hub, though. The compose file specification is versioned separately, and will outlive Docker, probably. So I don’t quite get your criticism?

How are you using compose without docker? They are joined at the hip, criticism of one is criticism of the other.

The days of cheap money are over, it's inevitable that certain SaaS companies will start tightening the screws on their users to match the returns they can get with cash in a bank. I just wish lxc (which docker was built off) got a chance to gain traction. It's miles ahead in DX and sure they serve different functionalities but can be used the same and the network effects can't be understated.

Re: Nginx Unit – Universal web app server

#163
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?

> How often do you need to add php support on the fly? Restarting the binary means you'll lose requests while it's restarting, so adding php (or whatever) support on the fly is what you need when running a system where losing those requests is material. Which it won't be for most people, but for, eg, Google (who don't use Nginx), losing those requests is a problem.

Neither Apache nor nginx require a restart to add php support, and neither will lose requests under normal operation. They will however parse the complete config on a reload operation. On huge configurations this is noticeable.

Re: Nginx Unit – Universal web app server

#164

Earlier quoted context omitted.

What’s the advantage of server side WebAssembly over just running a Rust/whatever application?

Security isolation too. I am using a WASM-based image processing pipeline for handling user submitted images. Much safer than trying to run a binary (Imagemagick, ffmpeg, etc) written in an unsafe language. In my case, the WASM does not have access to anything outside the sandbox.

Have you compared how much performance overhead has such sandbox in comparison to native (Linux) binary? Especially video processing. I just wonder if WASM app can even benefit from SSE4 or AVX instructions.

Re: Nginx Unit – Universal web app server

#165

Earlier quoted context omitted.

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.

php-fpm & nginx -g "daemon off;"

this is … not how I’d do it

Re: Nginx Unit – Universal web app server

#167
post #152

Earlier quoted context omitted.

Although it doesn't directly go against what you're saying, many Unix daemons have supported HUP signals for decades which can achieve the same outcome. No need to configure via API, just change the configuration on disk and send HUP. I suppose arguably that becomes a bit trickier for containers, so perhaps that's why you'd want to configure via an API?

To me this is identical - mutable state is mutable state, whether it starts on disk first makes no difference.

There is a slight difference to me as having another service run (the API) is an additional attack vector to worry about from a security perspective.

I would also say it's easier to enforce good "IaC hygiene" when the configs are managed via configuration files. They can go through a code review process, deployed via existing config management systems etc.

Re: Nginx Unit – Universal web app server

#168
post #56

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.

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.

My previous company ran quite a bit through asp.net running in Linux docker containers in k8s etc. I hardly consider it extremely rare.

Re: Nginx Unit – Universal web app server

#169
post #98

Earlier quoted context omitted.

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/

The type support in OpenAPI is fairly good (enough for us), and using a tool directly built on our stack allows nice things. Thanks for the link though!

AFAIK this is just a frontend Postman replacement which also supports OpenAPI, no idea how much it differs from showing the underlying type support from OpenAPI specs tho, seems to use collections so probably accepts postman ones to import. dunno just saw the other day on show hn
Post reply on HN