[racket] Web Application Deployment
Karl Winterling
to deploy Web applications. Is it possible to deploy applications on
shared hosting with Apache and something like CGI or FastCGI?
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
Neil Van Dyke
Racket (PLT Scheme) CGI-based application to SCGI using
"http://www.neilvandyke.org/scgi-scheme/".
For new development, consider using the PLT Web Server instead of SCGI
or old CGI. Nowadays, virtual servers like Amazon EC2 are affordable,
and you can make them do things that the cheapo CGI/PHP/Zope shared
hosting of a few years ago didn't support.
When undertaking a Web development project in Racket... in addition to
the extensive Racket documentation and the help available on this email
list, there are professional Racket consultants available for
outsourcing. And, to borrow a line from an Asimov bio, they grow more
handsome with each year.
Karl Winterling wrote at 06/22/2010 02:45 PM:
> It appears that you need a PLT Web server running on your site's host to deploy Web applications. Is it possible to deploy applications on shared hosting with Apache and something like CGI or FastCGI?
--
http://www.neilvandyke.org/
Karl Winterling
Warcraft account. However, I might try to design and "sell" a Racket
application to my Co-op. so I'll need to avoid sounding mentally
disturbed to the central IT staff.
Matthias Felleisen
Go for the CGI library then, it works well and patches are welcome
Anton van Straaten
> I'm a college student in California, so I can't afford a World of
> Warcraft account. However, I might try to design and "sell" a Racket
> application to my Co-op. so I'll need to avoid sounding mentally
> disturbed to the central IT staff.
Be aware that IT staff might be a bit reluctant to deploy traditional
CGI applications these days. Traditional CGI invokes an executable on
each request, which tends to put unnecessary load on servers,
particularly if the application has many users, or if it's public and
has search bots crawling it.
The P languages, Perl/Python/PHP, have long since moved to using either
modules integrated with the web server, or FCGI/SCGI approaches where
you need a separate server running the application anyway.
If FCGI or SCGI are options, then a third option that might be open to
you is running a Racket web server on a non-standard port and having IT
set up proxying to expose that server through their primary web server.
That takes just a few lines of configuration on most major web
servers, and it doesn't require any special protocols, libraries, or APIs.
Anton
synx
I looked over the FastCGI and SCGI protocols, and concluded that they
weren't much more efficient than a protocol known as HTTP. Why not proxy
your data to a webserver, using apache's proxy module?
My apache2.conf has a lot of these in it:
<Location "/z/">
ProxyPass http://127.0.0.1:6666/ retry=10
</Location>
If you can run a CGI program that launches Racket on some script file,
then you also have the ability to run Racket as a little web server. If
you can run Racket as a FastCGI server, or a SCGI server, then you also
have the ability to run Racket as a little web server!
Ken Struys
You get:
- Any almost any OS you would want
- root access to your vm (install whatever you want)
- a dedicated IP
- 256MB Ram
- 200GB/month in bandwidth
- 5GB disk space
Ken Struys
Jakub Piotr Cłapa
> I looked over the FastCGI and SCGI protocols, and concluded that they
> weren't much more efficient than a protocol known as HTTP. Why not proxy
> your data to a webserver, using apache's proxy module?
I recently looked at FastCGI and came to the same conclusion. To be
honest SCGI is somewhat simpler since it handles most of the validation
and parsing for you. FastCGI is not since it adds much of it's own
boilerplate. FastCGI can be used for some other task than simple HTTP
proxying (e.g. delegating authentication) but AFAIK nobody is using it.
> My apache2.conf has a lot of these in it:
>
> <Location "/z/">
> ProxyPass http://127.0.0.1:6666/ retry=10
> </Location>
>
> If you can run a CGI program that launches Racket on some script file,
> then you also have the ability to run Racket as a little web server. If
> you can run Racket as a FastCGI server, or a SCGI server, then you also
> have the ability to run Racket as a little web server!
That is the approach I settled on too (with nginx as the proxy). Just
remember to bind the racket app to "localhost"/127.0.0.1 and no to a
public interface.
--
regards,
Jakub Piotr Cłapa
Neil Van Dyke
> On 23.06.10 00:10, synx wrote:
>> I looked over the FastCGI and SCGI protocols, and concluded that they
>> weren't much more efficient than a protocol known as HTTP. Why not proxy
>> your data to a webserver, using apache's proxy module?
>
> I recently looked at FastCGI and came to the same conclusion. To be
> honest SCGI is somewhat simpler since it handles most of the
> validation and parsing for you. FastCGI is not since it adds much of
> it's own boilerplate. FastCGI can be used for some other task than
> simple HTTP proxying (e.g. delegating authentication) but AFAIK nobody
> is using it.
The main reason not to use FastCGI is that it's a seriously ugly
protocol. :) I had it almost completely implemented in PLT before I
decided that a custom Apache module or HTTP proxying was more sane, and
then I found the almost-too-simple SCGI protocol.
We've had good success with moving a large legacy system to SCGI, and
SCGI is proven by others (Ruby, Python, etc.). That said, HTTP proxying
is better if you want to do *everything* in Racket code, since then your
system is no longer dependent on mod_scgi and scgi.ss. Also, that keeps
you closer to using the PLT Web Server, which is a good place to be the
next time you need to rapidly whip up a new Web service or site or
internal tool or something.
--
http://www.neilvandyke.org/
John Clements
On Jun 23, 2010, at 7:33 AM, Ken Struys wrote:
> Oops forgot the link: http://pandela.com/
FWIW dep't.:
Linode ($20/month) sounds better than this (16 GB, 512 MB ram, etc.).
John Clements