There is something that should be said about nginx's third party modules. There are many and they add quite a bit of functionality, especially when they're upstream modules.
It's great because you don't even need a web framework, really. If you're comfortable and confident in nginx you can get quite a bit of performance out of the server while adding your application logic to it. I'm not sure why more people don't and just use it as a reverse proxy.
I don't know - I switched from Apache to NGINX because I preferred it's config formatting over writing XML when I stopped using things like CPanel. Many of the NGINX servers under my current role run the NGINX Lua module performing logic on over 1B requests per day. I do try to reduce dependency on modules, but that's not because it makes it too Apache-like, it's for simplicity's sake. If you don't want NGINX to have these features, don't compile it in, then boom. no longer bogged down.
For a more mature implementation of this concept, I would highly recommend having a look at Kore: https://kore.io
It has a sane architecture, and is fully privilege separated by default, with private keys isolated in a separate process. I've been using it lately to write REST APIs in C, and the experience has been awesome, it has great APIs to parse requests and easily construct responses.
Could someone explain to me why would I choose this over https://github.com/openresty/lua-nginx-module ? It supports LuaJIT and while I suppose it is possible to write faster C code by hand than JIT translated Lua it'd be hard and I'd fear the maintainability of hand optimized C code.
For one thing, you don't have to use this module with C. Any language that supports exporting C-compatible functions will do – there's C++ of course, but also Rust, Go, D, Nim, and many many others.
LuaJIT also supports C-functions. It's FFI [0] will allow you to declare any C-compatible function or data structure, and then use it in normal Lua code.
Sadly, the reason that discipline is such a vaunted virtue is because it's hard. Even the most well meaning and diligent C developers still make mistakes.
Tools should be ergonomic, they should reduce the need for diligence, care, discipline, and intelligence.
I'm not saying that the above aren't all important to programming, or that we should abandon anything that's not easy, but we're humans and make human mistakes and tools that are unforgiving when we do are ripe to be replaced by those that nudge us back on track.
Mostly the compiler just needs to slap your hand harder, and tell you no when you do something stupid or depend on undefined behavior. Also better static analysis would be nice.
I completely agree with you on all points. Languages exist to make our lives easier.
Well, there's a little more than that, as we actually have told compiler devs we don't want that.
When developers demand that compilers compete with each other on fractions of a percent of runtime performance, we set ourselves up for things like UB acting in unintuitive ways. When people give us the choice between safer but slower systems, and fast but unsafe ones, until recently people have overwhelmingly chosen fast and unsafe and pretended they're superhuman enough to not write bad code.
This is probably too much to ask for. I recently fixed an issue caused by UB in openresty of the form "nginx uses a NULL pointer and a length of 0 to signify a null string" + "nginx sometimes searches for strings in other strings using a function that takes start and end pointers for the haystack". This function works fine on lots of 0-length haystack strings (probably returning no match), but as you probably know, NULL + 0 is allowed to evaluate to anything. This seems pretty hard to detect statically short of banning programs that do arithmetic on any pointer without first NULL checking it.
That's why we choose to use C and do the other things, not because it is easy, but because it is hard, because that goal will serve to organize and measure the best of our energies and skills.
Hmm.. I've tried luaJit module and I've given up half way when building as it seemed a lot of compatibility issue(maybe not professional enough to build), sincerely I don't know lua and I prefer go for c module over any other language mixed together since nginx is build from C
For nginx-c-function, it's easy build and I can build this as dynamic module and use it with other servers which has same version of nginx.
It might be good to use lua if the person not good in c/c++.
The requests per second will drop by about 40% of what you'd otherwise get. This is with 4 workers, the worker_rlimit_nofile set to 262144 etc, etc.
I'm not sure what I'm doing wrong. It is pretty nice given that you also get all of the other options like upstream handling and reverse proxying and pretty damned good speed. The flexibility this adds is beyond awesome. But if I only need max speed for an api that only talks to postgres, redis, and a few other things, I'd just use H2o.
https://www.nginx.com/resources/wiki/modules/
It's great because you don't even need a web framework, really. If you're comfortable and confident in nginx you can get quite a bit of performance out of the server while adding your application logic to it. I'm not sure why more people don't and just use it as a reverse proxy.