6 ms·

Nice idea, bring back the old Common Gateway Interface for web development.

• chii 6y ago
  the cycle of technology. What is old will be new again.
  • reddec 6y ago
    Exactly! Just adapted for a new reality. And I found it quite exciting to adapt old proven technology to a new stack
• josephcsible 6y ago
  Won't happen for anything serious, because a process per request doesn't scale. FastCGI is probably as close as anything modern will ever get.
  • reddec 6y ago
    The point is to use low-end machines for a number of logic that 99% will do nothing. As example: webhooks. In this scenario there is no need for high performance/low latency but there is a high demand of low resource usage. However there's a way to scale it horizontally using shared storage. But it should out of scope. Btw I am author of it and I will be happy to answer on any questions. Thanks for your interest!
  • zwetan 6y ago
    moving from CGi to FastCGI is pretty easy
  • aidenn0 6y ago
    The problem with fastCGI is that it's only very slightly more complex to write a web server compared to a fcgi server
    • Lammy 6y ago
      I would like to take the opportunity to praise PHP (for once) for having PHP-FPM built in since PHP 5.4: https://php-fpm.org/ https://php-fpm.org/
      • peteretep 6y ago
        In my opinion, PHP edged out Perl for a similar reason, in mod_php. mod_perl you had to write thought-out classes for, configured the server, etc, where mod_php you just uploaded the .php files and got (comparatively) blazing fast performance that Perl CGI couldn't match.
        • throw_m239339 6y ago
          The only reason PHP edged out Perl is that one could mix-match HTML and PHP in the same page. Which is ironic when professional PHP tries so hard today to look like JEE.
          • ivanhoe 6y ago
            IMHO not quite, perl's Mason was actually very easy to use. Thing was that mod_perl was a major PITA, you had to restart the server after each change to the code, it was integrated deeply into the apache request flow giving you millions of ways to shoot yourself in the foot, shared state meant that it was super easy to kill memory, etc. It was just too complicated and messy, also often unstable. And on the other hand you had PHP that was simple, had clean state flow and fast execution, and was much more html/web oriented: tons of ready to use functions, easy access to GET and POST variables, cookies, etc. In that moment it was a blessing.
    • tannhaeuser 6y ago
      Exactly. You could as well use a load balancer to proxy incoming requests to your own pool of backend "functions"/processes each linked to eg. nghttp2. Would have the benefit that your "functions" can be executed independently, or from the command line, like CGIs.
  • naniwaduni 6y ago
    It's easier than you might expect not to need to scale beyond what a 2017 OS can handle with a process per dynamic request.
  • tannhaeuser 6y ago
    I think the word you're after is latency, because scalability isn't the issue. CGI-hosted web apps tend to use fronting HTTP caches plus memcache-like distributed caches or RDBMSs for app data once a request has actually resulted in a process being spawned. Historically, what's slow about pure CGI/process-per-request architectures are dynamic language runtimes that need to parse the entire CGI implementation code for each request (like old mod_php/mod_perl). That source of slowness can entirely be eliminated by using natively compiled CGIs. IMO FastCGI, or any other architecture inviting huge long running userland processes without GC, always end in robustness problems, memory fragmentation and grave security issues due to lack of process isolation, and still have about the same overhead as process creation in process-per-request architectures. What may help is a way to supply CGI params (PATH_INFO, QUERY_STRING, etc.) not via environment variables, but via eg. sockets, such that a number of pooled CGI processes can be started ahead of time, before a request is coming in.
    • vidarh 6y ago
      Indeed we ran a ~2m user webmail service as a CGI written in C++ ~20 years ago. We addressed latency aggressively by statically linking and never explicitly freeing memory except if we really had to - the processes were short lived; better to let the OS just dispose of everything at once. The process overhead was not a big deal even on 20yo hardware, and it saved us from dealing with all kinds of awful isolation issues. We discussed fastcgi or the like and dismissed it because the latency savings were much smaller than one might expect exactly for the reasons you mention: The problem was much less the process creation overhead than the overhead of dynamic runtimes. People also seem to have forgotten what was expected back then. The time it takes to load Gmail for example would have been totally unacceptable. Our biggest latency limitation was not the web server / CGI, but optimizing the mail storage backends, so that is where we spent our effort.
  • anewvillager 6y ago
    It scales if you let userland do thread scheduling (instead of having green threads on top of OS threads) Something like https://docs.microsoft.com/en-us/windows/win32/procthread/user-mode-scheduling https://docs.microsoft.com/en-us/windows/win32/procthread/us... See also https://news.ycombinator.com/item?id=6726357 https://news.ycombinator.com/item?id=6726357
    • josephcsible 6y ago
      I'm not sure how threading is relevant. CGI inherently requires a new process per request, regardless of any choices you may make about threading.
  • mhd 6y ago
    There also was SCGI as something easier to implement than FastCGI, but allowing for persistent processes. So I'm sure one could come up with yet another CGI version that's slightly better tuned for a different need and still retains the massive name-brand recognition of "CGI".
  • justinmeiners 6y ago
    > because a process per request doesn't scale Tell me more about why. The fork time isn't that many multiples more than spawning a thread. COW ensures you aren't using much more memory. You can always cap it at a pool of ~64 processes to handle requests.
• taneq 6y ago
  You’ve just invented the next big thing: Serverful Architectures!
  • est 6y ago
    You mean SPAs that renders on servers?
  • fiddlerwoaroof 6y ago
    If you think about it, the old virtualhost hosting providers were the original serverless providers: you didn’t run a server, you just uploaded your code and they ran it on their infrastructure.
• at_a_remove 6y ago
  I am pretty sure I have some old scripts using python's cgi module in production somewhere. They get about seven hits a day and have never gotten more than ten, nor will they ever, so scale here is irrelevant. Sad to hear that it has been deprecated.