-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
> How do you handle DB connections?
Look at
https://github.com/John-Nagle/vehiclelogserver, which has database connections.
Each FCGI program has a database connection. That database connection persists as long as the program instance is running. So it's not establishing a new database connection for each transaction.
Recently I enjoyed some "retrofuturistic" development with WASM and CGI. Spin[1], a webserver written in Rust, can execute WASI[2] binaries that speak CGI. You can then deploy it to Fermyon Cloud or your own server and it "just works". It's a wonderful mix of old and new. I used it for PHP (Prolog Home Page): https://github.com/guregu/php
[1]: https://spin.fermyon.dev/
[2]: WASI is a POSIX-ish standard for WASM that gives you all the low level stuff like standard input and output. It includes all the bits and pieces needed for CGI to work.
I felt exactly the same as the author. That's why I created https://trusted-cgi.reddec.net/ (currently on the way to v1 and under the heavy refactoring)
I appreciate this post, thank you for writing it.
There is something elegant about PHP and CGI. Just put file somewhere and query it by browser.
How would you fix the design of PHP and CGI to be scalable?
I wrote a userspace scheduler that multiplexes lightweight threads onto kernel threads. It is a 1:M:N scheduler since there is a scheduler thread that preempts other thread's loops. I think I can write a runtime that uses files. I also have an epollserver. If I merge them together and write a HTTP router, then in theory you could have a modern server runner that can execute in-process with threads.
https://github.com/samsquire/preemptible-thread
> Zero external configuration, other than telling your webserver to enable CGI on your file
This is only true if you've done it before, and know what you're doing. In reality, it looks like a mess of `mod_cgi` configuration, trying different combinations of file permissions, finding the magic `cgi_bin` directory, finding the right obscure log files when there are inevitably errors, wrestling with CORS and other subtleties of HTTP headers, and other complexities that are only easy to navigate if you're already an experienced CGI user.
That being said, I love the philosophy of using CGI for scripts. Instead of using CGI itself, though, I wrote a (single-file, statically-linked) web server called "QuickServ" to bring this philosophy into the twenty-first century. It has all of the upside of CGI, but is much easier to set up and run, especially for beginners.
One of its benefits is that it automatically parses submitted HTTP forms, and converts the form fields to command line arguments. That means it's extremely easy to put existing CLIs on the web with minimal changes other than writing an HTML form front-end.
If you like CGI, I will (shamelessly) ask that you check it out!
https://github.com/jstrieb/quickserv
https://news.ycombinator.com/item?id=29002694
Last time I used Perl for anything web it was via https://mojolicious.org/
It even does event-based and websockets
I wrote Eksi Sozluk, the most popular Turkish social platform to date, back in 1999 using Delphi as CGI executables[1]. Delphi was the tool that I knew best, and CGI worked for me at the beginning. I almost immediately started having problems with EXE files constantly active, making updates impossible (as it was Windows based), which required restarting the server for any kind of update.
CGI executables also caused problems when I switched to an Alpha AXP RISC server which emulated x86, bringing the performance to a crawl. That made me switch to classic ASP, and about 10 years later, to ASP.NET MVC with routing, unit tests, abstractions, jQuery, all the shiny things at the time.
Web didn't stop there of course; there came SPA's, React, Vue and whatnot.
Now, seeing the yearning for CGI in 2023 feels funny. Have we come full circle? :)
___
[1] https://github.com/ssg/sozluk-cgi