Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I recommend CGI instead of web frameworks

halestrom.net

Post reply on HN
Print view View original

61–70 of 89 posts

Re: I recommend CGI instead of web frameworks

#61

Post by oblib »

I still use Perl CGI scripts for handling chores on the server side.

The newest version of my app uses service workers to store almost all the app code in the user's browser. Almost everything the user does with the app is done on the client side so for the most part they only hit the server to get or put data in the server side database (CouchDB) and for the most part those are very small gets and puts.

Compared to earlier versions going back to 2002 my server barely has any load on it. If your goal is to track every click a user makes then CGI isn't a great server side option, but if your goal is to make a fast and reliable app than an offline-first/local-first side benefit is you don't need a huge box or tons of bandwidth to run it and CGI scripts are a fine way to handle small server side chores, which is pretty much all that's left.

Re: I recommend CGI instead of web frameworks

#62

Post by swamp_gas »

bawolff wrote: post #43
user5994461 wrote: post #37

Earlier quoted context omitted.

It's unusable today, more so than it was a decade ago: - modern frameworks have a much higher startup time (see Python imports, Java VM and other). CGI was fine to run a perl script with no dependencies. - it prevents any form of caching. caching is very important for many use cases. - it requires to open a fresh connection with every request, to the database and elsewhere (too bad if you thought you could use redis…

> it prevents any form of caching. caching is very important for many use cases > it requires to open a fresh connection with every request, to the database and elsewhere (too bad if you thought you could use redis for caching). nutcracker, twemproxy?

apache caching reverse proxy even.

Re: I recommend CGI instead of web frameworks

#63

Post by laurencerowe »

JulianMorrison wrote: post #16
laurencerowe wrote: post #12

The reason most Python folks moved away from CGI more than two decades ago now is that the performance is terrible. The interpreter startup time (plus any time executing module imports) has to run per request. This is much less of an issue for shell scripts which startup very quickly. The programming model does have its advantages though. Persistent servers risk leaking information across requests (seems to be a part…

You'll find that the isolation goes out of the window when you need sessions; they need to be stored somewhere that persists across requests.

Where sessions are too large to store in signed cookies (which should usually be preferred when possible since they require no extra infrastructure and avoid any risk of session data mixups) they normally end up in some kind of database or memcache since you likely want to support multiple processes.

It's much less likely you'll lookup the wrong user's session than accidentally store some user data in a module or closure variable shared between requests which may come from different users.

Re: I recommend CGI instead of web frameworks

#64

Post by ufmace »

I can agree in that CGI is a cool and simple technology that might make sense for some applications, and can be a good method to teach new developers the basics. I don't think I'd choose it for much now though, unless I knew it was very simple and would never grow more complex.

Most of the complaints here are about performance. I don't think the decreased performance would be much of an issue until you get to pretty large scale. I do think the real issue is the huge complexity in doing things correctly and securely in such a manual environment. Oh, you're going to do cookies by just printing the Set-Cookie header manually? Well now you have to handle everything about your cookies manually and do it correctly. What are the odds you're doing that? Just let Rails etc handle it the right way for you. Going to do CSRF protection manually too, and do anti-XSS escaping correctly everywhere, and mitigate a ton of obscure security issues that most people have never heard of? No way, unless you're a world-class expert. Just use one of the major proven frameworks that already take care of all of that stuff for you.

Re: I recommend CGI instead of web frameworks

#65

Post by gnabgib »

mongol wrote: post #38

An interesting companion may be althttpd, that runs the Sqlite website: https://sqlite.org/althttpd/doc/trunk/althttpd.md Heard about it in the Changelog podcast the other day.

It was recently featured on HackerNews: https://news.ycombinator.com/item?id=27431910

Re: I recommend CGI instead of web frameworks

#66

Post by laurencerowe »

alisonkisk wrote: post #55
laurencerowe wrote: post #12

The reason most Python folks moved away from CGI more than two decades ago now is that the performance is terrible. The interpreter startup time (plus any time executing module imports) has to run per request. This is much less of an issue for shell scripts which startup very quickly. The programming model does have its advantages though. Persistent servers risk leaking information across requests (seems to be a part…

Fastcgi solved that specific problem about minutes after CGI was invented.

FastCGI is pretty much equivalent to proxying to another HTTP process (though it does make it easier to share authentication information from the http server to the proxied process.)

Re: I recommend CGI instead of web frameworks

#67

Post by whelming_wave »

midasuni wrote: post #54
bawolff wrote: post #47

Earlier quoted context omitted.

I think its just that everyone on hacker news likes to pretend they have to scale to the size of google even though most people aren't even in the same ballpark.

Currently trying to order room service in a hotel from xxxxx.menu.org.Uk It isn’t loading, just sits there spinning. Pile of shit. I wish they’d chosen to write the service as a reliable cgi rather than some web framework where errors are eaten and hidden in Ajax calls. Uber eats let’s me place the order then vanishes when it comes to paying. Nandos yesterday told me error UK03 when I tried ordering in the restaurant…

I mean, on the other hand you could be dealing with an unreliable CGI-served page where errors are eaten and hidden in ajax calls, wishing they’d used a reliable javascript framework[1] instead.

[1]: an oxymoron, I know

Re: I recommend CGI instead of web frameworks

#68

Post by jagged-chisel »

speedgoose wrote: post #27
jagged-chisel wrote: post #11

Earlier quoted context omitted.

How do those web frameworks gain the ability to process things in parallel? What prevents a ‘single process’ from adopting those same methods?

Those web frameworks are lower level and have an embedded HTTP server designed to process things in parallel. It's in the standard library in golang or nodejs for example.

Sounds like one can use libuv in a CGI project and gain the same parallelization.

Re: I recommend CGI instead of web frameworks

#69

Post by coldtea »

user5994461 wrote: post #37
simonw wrote: post #17

CGI really is a beautiful abstraction. The reason we stopped using it 15+ years ago was performance: forking a new process for every incoming web request just didn't make sense on ~2000 era hardware. I wonder how true that is today, given that our machines have vastly more RAM and CPU? If you squint at them the right way AWS Lambda functions are pretty similar to the CGI model.

It's unusable today, more so than it was a decade ago: - modern frameworks have a much higher startup time (see Python imports, Java VM and other). CGI was fine to run a perl script with no dependencies. - it prevents any form of caching. caching is very important for many use cases. - it requires to open a fresh connection with every request, to the database and elsewhere (too bad if you thought you could use redis…

>- modern frameworks have a much higher startup time (see Python imports, Java VM and other)

That's fine, they can keep. TFA suggests using CGI in lieu of modern frameworks, not WITH modern frameworks.

>- it prevents any form of caching. caching is very important for many use cases.

No, it really doesn't. You can cache whole responses with a reverse proxy on top, or you can cache complex results in whatever (Redis, disk, etc) and query it from the CGI program.

>- it requires to open a fresh connection with every request, to the database and elsewhere

Which might be fine. MySQL for example is notoriously cheap to connect to for each request. Redis as well. (And you can always bump CGI to FastCGI).

>- SSL is everywhere and it has a notable overhead on initialization, meaning you really wish you could reuse connections

You can terminate SSL on your proxy, so that's not a issue.

Re: I recommend CGI instead of web frameworks

#70

Post by czx4f4bd »

wazoox wrote: post #46
Gaelan wrote: post #32

There's an important point I haven't seen discussed yet: I don't believe it's possible to write secure web apps without a templating engine with safe-by-default XSS handling (i.e. interpolated text is sanitized, unless explicitly marked as trusted HTML somehow), which implies some amount of a web framework or at least a web-specific library.

For these there's good old "perl -T" :)

How does perl -T protect against XSS?
Post reply on HN