Is there any advantage to using a web framework with http server like Jester or Prologue instead of the FastCGI protocol to serve web content?
Both the Jester and the Prologue need NGINX or Apache in the front for https and compression like FastCGI.
It makes sense to waste time developing a FastCGI framework in Nim? or is the FastCGI protocol condemned to disappear?
Does someone have an opinion about this?
Well, if you already have a good http server, why do you ever need a FASTCGI protocol implementation?
In addition, the fact that you need a frontend for https or compression does not mean you cannot implement them, as a part of the HTTP protocol, and get rid of NGINX or Apache. As far as I know, you cannot implement them with FastCGI.
FastCGI is an easier to implement protocol, and there are some utilities that allow you to spawn several processes, so you can use it with languages that do not have a proper http server to give them access to the web landscape, but I do not really see the point of using it if you have an http server.
For my understand, if we were on the case that server app cache don`t work well, such as GraphQL request with Json body by POST, FastCGI is more efficient as much as reducing process generating.
Is this wrong?
Because app program does not need fork a new process for each request...
Sorry I`m not sure at all.
Yes it is possible to implement https and compression and even http/2, but I don't believe that in the near future it will be available in the Nim, moreover http/2 is a complex protocol to implement. So whatever Nim web framework we use, we always need Nginx or Apache.
But even http/2 will be replaced by http/3 soon.
I believe that FastCGI is more scalable and should work in the future with any http protocol due to php.
FastCGI adds overhead and is hence slower than to have the http server and the "app" code rolled into one. Not only does one need sockets (even if fast domain sockets) which need to be written to and read from twice but one also needs to shift data around.
Re your last post ("http/2", etc):
Maybe. Or maybe not. For one, NO, http/3 will not be in widespread use anytime soon. Also the fact that http/2 is a complex protocol may turn out to be less of a concern, especially for us Nim'ers a) because there is a - relatively easy to wrap in Nim - library available, and b) because Nim happens to be a language that is particularly well suited to implement such a protocol.
As for PHP I don't know as I lack experience both in using PHP and in stirring cat and dog poo.
Btw., no,I'm not in any way against FastCGI, I liked to use it myself, but I see the context in which and when FastCGI was designed and desirable vs. todays situation.
I don't think FastCGI is the way to go. It's old tech we have better systems now.
Usually how high performance sites work is they host the static portion like HTML/JS/CSS/Images on a CDN. While the dynamic server cluster only does REST/GraphQL/WebSocket requests usually on an api.* domain. You use a proxy like Nginx or HAProxy to route between your different dynamic servers in your cluster.
Non of it involves CGI.
Creating an HTTP/1.1 web server is a simple and trevial task, so there are many web frameworks in Nim.
But, writing a server from scratch or using a library for http/2 or http/3 is completely different. It is a huge task.
You can check the libraries: https://en.wikipedia.org/wiki/HTTP/3#Libraries
The http/3 is the future.
I think We will have QUIC support soon(at least wrapper support).
Thanks @xflywind, this is good news :-)
This is the best example I found that shows the advantages of the http/2 over the http/1.1. https://http2.golang.org/gophertiles
Each square in the image is a connection to the server.
Jester and Prologue could use http/2 too except Server push or so.
http/2 is based on http1.0, so just configuring nginx should be enough.
I doubt http/2 and/or http/3 (QUIC) makes sense for most Nim applications. You should be reverse proxying Jester using nginx (or another http server) anyway, and I'm sure it can take care of HTTP/2 for you (as well as http/3 too).
Also, if you're deploying your site to the world you'd likely want cloudflare in front of it, which will also deal with these new standards for you.
As for FastCGI, as far as I'm concerned it's pointless. I'd love to see benchmarks showing that it's faster than simply reverse proxying an HTTP server, so far I don't believe it makes a significant difference to the speed. So maintaining support for it seems like a waste of time.