If you’re using CGI or FCGI, then you’re using a general web server that is probably serving lots of different applications.

These days, folks often write the app to contain a web server. Write your app in JavaScript, pull in a dependency that serves HTTP, write enough code to route requests and start the server listening- welcome to Node. Python and Ruby offer the same. Swift gets this functionality from Kitura and Vapor. I’ve experienced C and C++ varieties.

Back in the day when Apache was seriously hot, mimicking today’s architecture would have meant writing an Apache module - the app would then live within the server and no communication channel/pipe/socket/fork/spawn would be required.

Yes but the poster, above, is complaining about using CGI with a server. My question is, if you're not using CGI/fastCGI with Apache or nginx for example, what is he suggesting should be used instead?

Ok, lemme spell it out: bundling the app and the server together; that’s what’s implied.

Which comes back to my question. Can one do that with apache and nginx? I'm pretty sure I've seen methods for this in Apache but only the paid version of nginx. Am I wrong?

Today, app servers are mostly separated from front-end servers because, it turns out, it's best to not hold on to too much memory and/or threads while waiting for a slow client to receive their stuff. So async servers like Nginx are used on the front tier and they knock to app servers over the net.

But Nginx does have a Lua module, and, I think, Perl. Afaik both are in the free version. Mostly used to augment configuration, or for lightweight interfacing directly with databases (ahem Redis and Memcached cough).

I mentioned Apache modules in my comment. Write a module, add it to Apache’s config, your code loads with the web server.

Looks like one can also write nginx modules, but I’m not familiar with nginx licensing to know if a purchase is required to use that in a commercial deployment.

It's not required, and in fact there's a big open source project taking advantage of that: OpenResty uses a module that loads LuaJIT into Nginx, and builds very fast applications into Nginx using Lua.

Using your language of choice: You open a socket on a port, listen for connections, when connection from client arrives read bytes from the socket, parse http request from those bytes, do something that may yield bytes in response, write the response bytes to the socket, close the socket (optional).

https://beej.us/guide/bgnet/

I asked about how to do this through apache or nginx. I know how to do it as you suggest.

You don't need a server like Apache or Nginx. Your code can just bind to 80/443 directly.

Yes you can but that has nothing to do with what I asked.

If you get the same answer three times but don't think any of them answer your question, maybe consider that you're the one failing to communicate.

You can also just serve HTTP.

That has nothing to do with my question. Of course you "serve HTTP". I want to know how one interfaces with a server without CGI or fastCGI.

You serve HTTP to the server. To the front-end server or the load balancer, aka ‘reverse proxy’. That's how.

Both Apache and Nginx can proxy HTTP, out of the box.

IOW, opening a socket from the routing HTTP server to an application HTTP server. That’s pretty much how FCGI works.

Yeah, people just seemingly realized that there's nothing special about FastCGI that couldn't be done with plain http. And as a bonus, the app itself can work as a server in the dev env, and testing is simpler.

(Only, CGI managed to get headers sorta right by embedding them in protocol vars and not the other way around.)

But I already do this and that doesn't answer the question about the difference between fastCGI and what everyone else seems to be using, but not explaining, is a method of direct integration or ability to talk with the server without CGI/fastCGI.

After doing a little research, it appears this can be done by implementing or writing modules that will talk directly to server internals if I'm understanding this correctly.

You don't usually need to talk to the server from the app. Pretty much the only thing needed in practice is returning an internal redirect that ends up served by another path (with error pages being variations of this). This is solved fine with an HTTP header in the response.

CGI and FastCGI actually have the exact same flow of information as HTTP (to my knowledge). Anything else is either implemented on top of that, or you'll need a module reaching into internal functions.