21–30 of 89 posts
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.
Earlier quoted context omitted.
How about FCGI?
I use FCGI with Go programs. FGCI is an orchestration system. Each worker process has a subroutine that's called when there's an incoming request, so the FCGI processes are reused for more than one task. The FCGI server will fire up more worker processes when needed, and ask them to exit when there's no work for a while. If a worker process crashes, a fresh copy is started. Every few minutes, each worker process is t…
So the remaining advantage to use FCGI with Go is that memory leaks would never be an issue?
I digress, learning CGI might be useful in a historical context but as others pointed out its pitfalls are large and there's a reason we don't use it anymore. If you've ever seen a mess of a perl and bash to try to serialize some JSON you'll know why. It encourages bad behavior that doesn't scale well.
If your students aren't understanding template generation and mapping routes to functions they probably lack a background in a lot of fundamentals. At best they'll simply copy and paste best practices without understanding why. I think taking a step back and looking at interops, FFI and APIs will explain why web servers and the web itself became popular. To understand that you begin to need to now the basics of operating systems and by default compilation and some other undergrad theories. These aren't taught just for fun.
That said modern web frameworks hide a lot and that's not necessarily a bad thing. In attempt to make things isomorphic and routing client-side the delineation between client and server is blurred. Even I had a had hard time figuring out whether things were rendered on the browser or the client-side and WASM blurs this further.
The weird late 90s derail into "just use Windows" is a huge red herring too. I use OS X, and I've used Windows. I spend most my day in a terminal or a Linux VM and still won't have Linux as my primary desktop. On the same hand if you've ever had to do something low-level on Windows or a Mac it is painful. See Linux's cpufreq vs whatever Windows or Mac has to deal with big-little CPU architectures. The trade off is that the desktop experience is brittle at best. That's okay there's a hundred of ways to develop for Linux on Windows and Mac, that's a solved problem.
I'm seeing a lot of React jockeys come out of bootcamps like these with a cursory understanding of computing. Similarly I see people come out of top colleges thinking they'll be perfecting algorithms in Rust. Neither is right, but the React jockeys are dangerous as they have a "works on my machine" mentality that a lot of us learned the hard way doesn't work. Now it seems you can sort of throw cloud resources to make it go away. I'm not saying everyone needs a CS but a fundamental understanding of what you don't know can go a long way.
Ruby, python, PHP every server side tech use FCGI at the backend, only exception being stacks that have built in webserver [Java].
FCGI works mostly like cgi, but the program doesn't terminate after execution, rather continues to listen for next request and serves it. Runs like a daemon.
I love the simplicity of CGI, it was ~2002 when I read about it in a book on Linux and had my first server-side generated HTML output a couple of minutes later. But: It has no place in todays world except of educational use. Especially the fact, that every HTTP request would spawn a full new process makes it unfeasible for any serious webapp.
I understand that they can solve the problem of horizontal scale as they are spawning a container rather than just a process, but surely if you started with CGI scripts it would be easier to move if you needed to at a later date.
Earlier quoted context omitted.
It's a bit better but one process can only process one request at a time. You need a lot more processes compared to a http framework processing http requests in parallel.
How do those web frameworks gain the ability to process things in parallel? What prevents a ‘single process’ from adopting those same methods?
Earlier quoted context omitted.
It's a bit better but one process can only process one request at a time. You need a lot more processes compared to a http framework processing http requests in parallel.
Fcgi apps can handle requests in parallel in a single process just fine, as long your environment supports it.
Earlier quoted context omitted.
How about FCGI?
I use FCGI with Go programs. FGCI is an orchestration system. Each worker process has a subroutine that's called when there's an incoming request, so the FCGI processes are reused for more than one task. The FCGI server will fire up more worker processes when needed, and ask them to exit when there's no work for a while. If a worker process crashes, a fresh copy is started. Every few minutes, each worker process is t…
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.