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

Ask HN: Modern approach to web application development with Common Lisp

news.ycombinator.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Ask HN: Modern approach to web application development with Common Lisp

#21

Post by gracchus »

Hunchentoot is a bit odd, but works well. In particular, the fact that handlers (think, like prefix-matching dispatch functions) are global, rather than per-listener. There is, in general, an apparent tendency to use var globals for expediency's sake, but they tend to infiltrate code, and make things harder to debug.

I concur with other commentators that PostgreSQL is worth looking at. I wrote the postgres bindings for what is now CL-SQL many years ago (hi stringbot!), and postgres is fast and reliable (aside from SBCL having interrupt hander sensitivities during ffi calls), though again, the CL-SQL interface is littered with globals, the connection pooling is a bit .. unusual .. and the reader macro syntax probably a pretty bad idea, all in all. If hunchentoot and cl-sql were mildly rewritten with an eye towards looking more like, for example, Java's JDBC and Servlet interfaces, you would have a simple base environment where you could reap most of the big CL wins immediately (DSLs, CLOS, coding closer to the speed of thought, etc.)

The 'IMHO' sources are kicking around here: they suffered a bit from WebObjects envy (hey, it was the 90's..) and do somewhat suboptimal handling of session state. It's still not clear to me how OO you really want to get with the server-side representation of a page, especially in light of all the nice JS client-side component kits that are around.

Mull.

Re: Ask HN: Modern approach to web application development with Common Lisp

#22

Post by vog »

gibsonf1 wrote: post #7

We've been using Portable Allegroserve + mysql (running on SBCL on EC2) with very good results.

I wouldn't count on MySQL anymore. Oracle recently attempted to remove InnoDB support (i.e. transactional safety) from the Free Software variant of MySQL:

http://www.h-online.com/open/news/item/Oracle-raises-prices-...

Although they took this back for the moment, allowing InnoDB to stay available in the "Community Edition", they made very clear that we can't count on that in the future.

So if you attach importance to ACID, I recommend to start with PostgreSQL rather than MySQL.

Re: Ask HN: Modern approach to web application development with Common Lisp

#23

Post by WalterGR »

sedachv wrote: post #17
WalterGR wrote: post #14

SproutCore + Hunchentoot + MongoDB is it right choice? Even then you're not yet off to the races. In particular, Hunchentoot's session management capabilities are anemic out of the box. I haven't seen any drop-in replacements, so you're looking at reinventing at the very least this extremely core part of any web development stack. Hunchentoot also doesn't have any built-in capabilities for handling updates to the web…

"In particular, Hunchentoot's session management capabilities are anemic out of the box." Do you mean user authentication? What would be really nice to have is a user authentication library that offered a generic protocol that could be used with several web servers and persistence mechanisms. "Hunchentoot also doesn't have any built-in capabilities for handling updates to the website's source code." You just load the…

Do you mean user authentication?

No, I mean session management. Example of anemia: it offers no way to back sessions by persistent storage.

You just load the new code and it works.

Really? What about threads that are busy processing requests when you load the new code, which may have different assumptions?

It seems like a better approach would be to queue up incoming requests, wait for existing requests to be handled, reload the code, and then resume processing requests.

Re: Ask HN: Modern approach to web application development with Common Lisp

#24

Post by sedachv »

WalterGR wrote: post #23
sedachv wrote: post #17

Earlier quoted context omitted.

"In particular, Hunchentoot's session management capabilities are anemic out of the box." Do you mean user authentication? What would be really nice to have is a user authentication library that offered a generic protocol that could be used with several web servers and persistence mechanisms. "Hunchentoot also doesn't have any built-in capabilities for handling updates to the website's source code." You just load the…

Do you mean user authentication? No, I mean session management. Example of anemia: it offers no way to back sessions by persistent storage. You just load the new code and it works. Really? What about threads that are busy processing requests when you load the new code, which may have different assumptions? It seems like a better approach would be to queue up incoming requests, wait for existing requests to be handled…

"No, I mean session management. Example of anemia: it offers no way to back sessions by persistent storage."

The session protocol is a bit awkward in that you need to implement all of it if you want to change only a small part, but it's there to be hooked into, which is what the frameworks built on top of Hunchentoot do. The support is there to have persistent session objects, you just need to find something that does that (I agree it would be great to have libraries independent of frameworks but built for specific DBs for this) or do it yourself (all that Hunchentoot requires for this to work is to implement two methods).

A lot of the time what you'd really want to do is subclass the session class to make it persistent through an ORM or prevalence, but the problem is that you can't just drop in arbitrary metaclasses into arbitrary subclasses in CLOS.

"Really? What about threads that are busy processing requests when you load the new code, which may have different assumptions? It seems like a better approach would be to queue up incoming requests, wait for existing requests to be handled, reload the code, and then resume processing requests."

You're talking about atomic change management. Queueing up requests works on a per-request basis, but what happens when your code changes affect existing sessions (for example, people in the middle of a multi-step order confirmation form)? The easiest way to do this is have multiple servers and switch them over one by one. In the more general case you need to think in terms of protocols and protocol versioning (http://carcaddar.blogspot.com/2009/03/p-cos-blew-my-mind.htm...)

Re: Ask HN: Modern approach to web application development with Common Lisp

#25

Post by WalterGR »

sedachv wrote: post #24
WalterGR wrote: post #23

Earlier quoted context omitted.

Do you mean user authentication? No, I mean session management. Example of anemia: it offers no way to back sessions by persistent storage. You just load the new code and it works. Really? What about threads that are busy processing requests when you load the new code, which may have different assumptions? It seems like a better approach would be to queue up incoming requests, wait for existing requests to be handled…

"No, I mean session management. Example of anemia: it offers no way to back sessions by persistent storage." The session protocol is a bit awkward in that you need to implement all of it if you want to change only a small part, but it's there to be hooked into, which is what the frameworks built on top of Hunchentoot do. The support is there to have persistent session objects, you just need to find something that doe…

Queueing up requests works on a per-request basis, but what happens when your code changes affect existing sessions

Good point.

The session protocol is a bit awkward in that you need to implement all of it if you want to change only a small part, but it's there to be hooked into, which is what the frameworks built on top of Hunchentoot do.

I notice you used the plural "frameworks" built on top of Hunchentoot. Are there any aside from Weblocks?

Re: Ask HN: Modern approach to web application development with Common Lisp

#26

Post by sedachv »

WalterGR wrote: post #25
sedachv wrote: post #24

Earlier quoted context omitted.

"No, I mean session management. Example of anemia: it offers no way to back sessions by persistent storage." The session protocol is a bit awkward in that you need to implement all of it if you want to change only a small part, but it's there to be hooked into, which is what the frameworks built on top of Hunchentoot do. The support is there to have persistent session objects, you just need to find something that doe…

Queueing up requests works on a per-request basis, but what happens when your code changes affect existing sessions Good point. The session protocol is a bit awkward in that you need to implement all of it if you want to change only a small part, but it's there to be hooked into, which is what the frameworks built on top of Hunchentoot do. I notice you used the plural "framework s " built on top of Hunchentoot. Are t…

RESTAS (http://restas.lisper.ru/en/) and web4r (http://web4r.org/en/) are both built on top of Hunchentoot.
Post reply on HN