42 minutes ago by 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.
18 minutes ago by 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).
an hour ago by rossmohax
nginx unit (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.
32 minutes ago by reddec
Interesting. Could be useful for high-load, however for quick setup feels like a little bit complicated. Are any known UI, or scheduler settings?
Following is a general response for similar questions.
I pretty sure it's possible to do the same thing as trusted-cgi by combining several tools: cron + nginx/nginx-unit + some deployment + stats + whatever.
It could be faster, more flexible, but... I am not sure that I will personally want to setup it each time for new boxes. Or write auto-install scripts. I would like to write logic, not make environment.
Benefits trusted-cgi are: low resource usage (very low), easy setup, web UI and focus on including several features in one package.
It's possible to find better solutions for each parts, but I would like hear product that providing complete solution instead of providing "bricks". I am a big fan UNIX way, but sometimes we need an assembled thing, instead of another piece of constructor.
5 hours ago by michael-ax
When I published webhub @ href.com in 1995 we called these 'custom runners'. Looks like you'd have approved of that concept :)
5 hours ago by reddec
Thanks for tip: several ideas from there look very promising
7 hours ago by 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.
6 hours ago by reddec
I hope, I fixed it
3 hours ago by ferzul
fine for me, firefox/android
9 hours ago by fouc
Nice idea, bring back the old Common Gateway Interface for web development.
6 hours ago by taneq
Youâve just invented the next big thing: Serverful Architectures!
3 hours ago by est
You mean SPAs that renders on servers?
8 hours ago by 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.
7 hours ago by tannhaeuser
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.
2 hours ago by vidarh
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.
8 hours ago by reddec
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!
7 hours ago by aidenn0
The problem with fastCGI is that it's only very slightly more complex to write a web server compared to a fcgi server
3 hours ago by tannhaeuser
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.
5 hours ago by 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/
4 hours ago by mhd
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".
8 hours ago by chii
the cycle of technology. What is old will be new again.
8 hours ago by reddec
Exactly! Just adapted for a new reality. And I found it quite exciting to adapt old proven technology to a new stack
6 hours ago by 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
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 :-)
6 hours ago by reddec
Great project! However, I think our projects similar but not the same. Looks like we can exchange some ideas from each-other
6 hours ago by 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 :-)
6 hours ago by 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 ;-)
8 hours ago by 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.
7 hours ago by 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..
7 hours ago by fiddlerwoaroof
Openfaas.com enables cgi-style applications to be run on k8s
7 hours ago by reddec
Heavy, very heavy. Even with k3s. I tried it first. Even plain k3s will run slowly on 1GB machine (a target audience)
3 hours ago by est
inetd was like what, eBPF hacks and sidecars?
Daily Digest
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.