
Rethinking of CGI as a selfhosted lambda server - reddec
https://trusted-cgi.reddec.net/
======
rossmohax
nginx unit ([https://unit.nginx.org/configuration/#process-
management](https://unit.nginx.org/configuration/#process-management)) does
something very similar. with `spare = 0` config option it will start app
process lazily and shutdown when idle.

There is support for Ruby, Python, PHP, Java, Node, Go runtimes.

~~~
xorcist
You can also use socket activation in uWSGI for this, together with a
reasonable value for die-on-idle.

What's nice about it is that applications run unmodified.

uWSGI really is the swiss army toolchain for web operations.

------
michael-ax
When I published webhub @ href.com in 1995 we called these 'custom runners'.
Looks like you'd have approved of that concept :)

~~~
reddec
Thanks for tip: several ideas from there look very promising

------
floatingatoll
OP, your site is unusable on mobile. I wasn’t able to read about your project
as scrolling causes it to force half the text and diagrams out of frame.

~~~
reddec
I hope, I fixed it

~~~
ferzul
fine for me, firefox/android

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

~~~
josephcsible
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.

~~~
aidenn0
The problem with fastCGI is that it's only very slightly more complex to write
a web server compared to a fcgi server

~~~
Lammy
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
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
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
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.

------
HelloNurse
Having first met Apache when Perl CGI scripts were bleeding edge fancy "web
app" technology, I hoped to read a satirical article, but it's actually an
earnest suggestion to go full circle.

It does less than proper CGI, due to giving up HTTP (particularly response
headers, status codes and content types) in order to process constrained JSON,
and it does it in a more complicated way (UI? Scheduler? Git repositories?),
but it's still better than other options.

~~~
reddec
To be fair I am not trying to say that CGI is a bleeding edge technology)

I met a problem: low-end devices that should host a big number of small pieces
of logic. To solve the problem I looked back to the history and found CGI and
adapted it to the specific case.

As someone said before here in comments: it's just reinvented "good old
technology", but I would like to say that I can't find anything bad in it. Old
technology means a number of documentations, it means easy to explain.

Ofcourse there are number of issues caused the technology became outdated, but
in some cases (defined in target audience) it acceptable. Even sometimes
better than newer solutions.

More of that, if you will look at the modern technology (serverless
functions/lambda functions) you probably will find the same ideas but wrapped
into modern solutions (containers and cloud).

------
adnanh
I did something very similar for handling webhooks (but can also be used for
anything else), check it out at
[https://github.com/adnanh/webhook](https://github.com/adnanh/webhook)

People have used it in various segments, from actual deployments on push, to
home automation, someone even wrote a guide on how to control the Xiaomi Robot
Vacuum using the Amazon Dash button :-)

~~~
reddec
Great project! However, I think our projects similar but not the same. Looks
like we can exchange some ideas from each-other

~~~
adnanh
Yeah, my guess is that they share the same concept - expose triggers via
HTTP(s) to run user commands. The webhook handling put on some additional
requirements on my project: to go a little bit beyond piping the input to the
script :-)

~~~
reddec
Right. Trusted-cgi also adds security checks (with various checks), "actions",
scheduler and web UI =)

I would like to suggest to stop measure benefits of both projects and just
"steal" them from each other, making end-user experience better for both
projects ;-)

------
readams
Losing the ability to stream the request and response is a big downgrade from
normal CGI. I'm struggling to see how this improves at all on it.

~~~
Matthias247
Why would you lose it? As far as I understand bodies are still streamed
through stdin/stdout. Are you concerned about the headers? You should have all
of those anyway before dispatching.

------
gavinray
Isn't this just OpenFaaS?

OpenFaaS has a single-binary distributable that doesn't require Docker/k8s
they released called faasd:

[https://github.com/openfaas/faasd](https://github.com/openfaas/faasd)

------
exabrial
> I also tried self-hosted solutions based on k3s but it too heavy for 1GB
> server (yep, it is, don’t believe in marketing).

ow.

------
tuukkah
Is this compatible with AWS Lambdas on some level? Could it be? What about
FastCGI/WSGI/... compatibility? I'm thinking it could be really nice for hobby
projects and for developing on a laptop.

~~~
reddec
Any script/application that can parse STDIN and write something to STDOUT is
capable for the project.

Hobby projects or projects with low number of requests are ideally fits. And
it could be run on very low-end devices: raspberr pi, cheapest VPS, etc..

~~~
fiddlerwoaroof
Openfaas.com enables cgi-style applications to be run on k8s

~~~
reddec
Heavy, very heavy. Even with k3s. I tried it first. Even plain k3s will run
slowly on 1GB machine (a target audience)

~~~
fiddlerwoaroof
Yeah, I was thinking about this as a migration path for scaling-out CGI
scripts

------
est
inetd was like what, eBPF hacks and sidecars?

------
kalium-xyz
We have gone full circle c:

~~~
waheoo
Im still trying to understand the difference between a .php file and a lamda
"serverless" application.

~~~
CGamesPlay
Well a php file (that isn't a library, so one that produces output) is one of
the things that you could write to be a lambda function. But not every lambda
function can be expressed as a php file. So I could download some video
filtering lambda functions and they can be written in anything, then I can
link them against my application, which I write in PHP.

The language/platform/dependency freedom is what takes it from literal CGI
script to lambda function.

~~~
naniwaduni
It took a moment of thinking to decide which of "literal CGI script" or
"lambda function" you were attributing "language/platform/dependency freedom"
to.

I would've attributed them to CGI.

~~~
CGamesPlay
Ah, that's fair. I was mostly attempting to highlight that a php script is a
subset of lambda functions (from a conceptual viewpoint). Of course it's also
a subset of CGI scripts as well (in a much more literal viewpoint).

------
_bxg1
a) This site is very hard to navigate; on mobile the text jumps around
whenever you touch and it's usually cut off past the edge of the screen

b) I couldn't figure out what this is. At first I thought it was computer
graphics rendering (what "CGI" usually means), but after skimming several
paragraphs I don't think that's what it is? But I'm still not sure.

c) Clicking the github link tries to download a .zip, which beyond making it
harder to figure out what this is, was mildly distressing.

Edit: re: the downvotes, presumably the author would want to know that their
site is broken on mobile and that the content is inaccessible to the average
reader who might be curious to learn about it, in ways that could be easily
remedied.

~~~
bdcravens
I think your downvotes are for your comment about CGI; while the term is
ambiguous, in the context of serving the web it refers to Common Gateway
Interface, the original method for serving anything other than static files.

[https://en.wikipedia.org/wiki/Common_Gateway_Interface](https://en.wikipedia.org/wiki/Common_Gateway_Interface)

For many HNers, this is an understood term.

~~~
_bxg1
I don't think it's unreasonable to ask that acronyms in general be expanded
towards the top, especially when there's a commonly-known overload in the same
general subject area. Personally, I've been working in the field for six years
and studied in it for six years before that, and I'm pretty sure I've never
heard that term. Simply writing out the full phrase "Common Gateway Interface"
would a) tell me it's not what I thought, and b) give me something to google
so I can learn about the subject and/or decide if I'm interested in continuing
to read.

~~~
catalogia
If you don't already know what 'CGI' means in this context, I'm skeptical that
"Common Gateway Interface" would actually resolve much confusion.

~~~
_bxg1
It would tell me that it doesn't have to do with graphics, and that it
probably has to do with networking. That's a whole lot more than is made clear
as it is.

