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.

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.

because you could do all that and more with apache modules, the reason people switched was because nginx didnt get bogged down in all that.

imho its keyword engineering, but you can see given the history why nginx adopters aren't thinking that way.

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.

Separation of concerns? Might be worth it, but there are tradeoffs in binding everything together.

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.

Genuine question here but why would you want to write REST APIs in C?

I’ve been writing C for 25 years and I wouldn’t trust myself not to do something stupid.

I preferred nginx over kore.io. The nginx can do a lot of things and been recognize by a lot of popular company

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.

[0] https://luajit.org/ext_ffi.html

Why would you ever opt to go thru Lua in this case?

It's well supported, well maintained, and around for the foreseeable future. (OpenResty)

The language implementation is fast, and allows you to tap into any C-compatible library.

The question isn't why you would go through Lua, but why you would choose something with less support?

This doesn't seem to support actually exporting C-compatible functions.

Create some Lua code that runs within C? Rather than just passing and converting to C values when needed?

That's the role of the C API [0]. But usually you'd just be passing C up to Lua to bind it together.

[0] https://luajit.org/ext_c_api.html

it's complicated

It's faster like you said. but probably the main benefit are people who have already developed a large program in C.

C isn't hard to maintain -- it's not some mystical language..

It just takes discipline. The discipline to not haphazardly throw macros all over the place, and keep them pure(no side effects).

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.

It might be easier to tie in a few different external libraries if you're using C than with Lua FFI, depending on the libraries.

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

Or something "lighter" like H20 with mRuby?

https://h2o.examp1e.net/index.html

We're huge fans of C interfaces on the sever side. https://kore.io is our preferred stack.

It's primary interface is C. In our opinion, it's lighter weight, and simpler to integrate with your app.

Is the function blocking or asynchronous? Cant quite find it in the README.

It works with nginx threads using aio. It's in one of the issues there if you look deep enough.

https://github.com/Taymindis/nginx-c-function/issues/2

I haven't figured out how to get rid of the drop in performance though. Lets say you just return a 200 from the nginx location like so:

  location /a {
        return 200 "{\"result\": \"Hello World!\"}";
    }

vs

    location / {
        ngx_http_c_func_call 'getRoute';
    }

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.

what is the src of the C function?

Check this file out, it's in the example that's provided: https://github.com/Taymindis/sample-ngx-cfunc-project/blob/m... I've stripped out everything of 'getRoute' and only provide a response of a global variable 'thing' that never changes.

  std::string thing = "{\"result\": \"Hello World!\"}";
  void getRoute(ngx_http_c_func_ctx_t* ctx) {
    ngx_http_c_func_write_resp(
                ctx,
                200,
                NULL,
                ngx_http_c_func_content_type_json,
                ::thing.c_str(),
                ::thing.length()
    );
  }

You should browse the WIKI => https://github.com/Taymindis/nginx-c-function/wiki

Can anyone explain to me what is the different between

ngx_http_c_func_call "my_app_simple_get_greeting";

vs

ngx_http_c_func_call "my_app_simple_get_greeting" respTo=myResponseVariable;

I didn't see any different, just create a variable.

I've got the answer. https://www.reddit.com/r/programming/comments/9nsbt8/create_...

cgi-bin all over again?

Not really. Cgi-bin processes were executed from scratch. This is a single function call from an dynamic lib.

Is this like lambda(aws) for C?

I suppose a procedure that responds to an http request is now called a lambda.

No...?

That's what it reads like, yeah.

Why does it keep mentioning .so? Nobody refers to it like that. Just say dynamically link.

Any idea why sharing this link to Pocket on Android 9 does not work? ("this webpage does not contain a valid link")