How to write and deploy a Lisp Webapp | Hacker News Reader

How to write and deploy a Lisp Webapp

blog.postabon.com

101 pointssmanek7 comments

Hi guys,

When I posted about why I chose Lisp for http://postabon.com a few weeks back (http://news.ycombinator.com/item?id=972248), I got a few people who were interested in a 'best practices' guide of how to write a Lisp Webapp.

This is by no means complete, but I hope it's a good start.

You should really refer to the language as Common Lisp to avoid confusion and annoy less people.

disclaimer: I'm a CL zealot myself and not in the slightest annoyed.

Thank you very much.

I am willing to explore Lisp as a web development language, but my knowledge of Python and Django (and Plone) are a hindrance in this scenario: the low-risk road is to go with what I know and is good (at least better than, cough, Java and .NET, cough) enough.

When installing sbcl on a fresh linux box, I don't get the distribution repo--in fact, I have heard that this is less likely to be supported in the future.

What I do is to grab a binary of sbcl from http://www.sbcl.org/platform-table.html, install it, then get the source and customize it for changes that I want as you have said. The build is fairly quick, except on my old PPC mac.

Nice writeup, and useful. I just did a git clone and looked through the project. I used to do web app development in Lisp and I found having a skeleton project to start with with all ASDF installs local helped me get started - in the future I am likely to toss my old skeleton project and use this one.

I see you're using nginx as the reverse proxy. There seem to be a lot of options for reverse HTTP proxying - nginx, apache (mod_proxy), lighttpd, squid, etc. Would you (and/or anyone else) mind talking about choosing the right one? I assume all of them support keeping connections to the backing servers alive to reduce the overhead from opening new TCP connections.

Apache seems overkill if it's not also serving up some of the pages, but other than that I'm a bit lost. I'm mainly after multiplexing requests to different server processes (some in VMs) based on Host: header and/or path. Applying gzip/deflate compression where the backing server doesn't support it would be nice too.

There is no support in nginx to do keep-alive connections to backend servers.

Placing nginx and the backend servers on the same LAN should make it less of an issue than high-latency frontend connections.

The backend response will also be buffered in nginx until it has received it all before the front-end user is served the request.

Reply on news.ycombinator.com