David, I'm in the same boat. I have an app I originally coded in Rails. Then I recoded it in Merb (much better, but now I'm unhappy with the merb-rails merger). I'm testing out lift now to see about recoding it once again before the app gets too complex. I also have another app or two to build and would like a single framework to grow with.
I'm not interested in ditching ruby/merb for performance reasons as merb is ok for my needs. I'm interested in lift as I would like one "go forward" language (I've been tracking scala for a few years now) and am not compeltely happy with ruby or its frameworks. Hope this list doesn't mind me peppering it with noob questions as I spend the next week or two seeing if I can quickly recode my app with lift. thanks, Jon On Feb 28, 6:21 pm, David Pollak <feeder.of.the.be...@gmail.com> wrote: > On Sat, Feb 28, 2009 at 2:37 PM, Ikai Lan <ikai....@gmail.com> wrote: > > > Hi, > > > I'm looking to learn Lift coming from working with Ruby on Rails for a > > while and I've been voraciously consuming the documentation and > > tutorials that are available on the internet. There are a few things I > > really like about Lift so far: > > > - Out of the box Comet support > > - Rapid development (incremental compiles are awesome) > > - Being able to design without having to think of the request/response > > cycle* > > > I'm putting an asterisk on the last item because I'm a bit confused > > how this will work in a production application running two or more > > load balanced Lift instances of the same application. > > You need a load balancer that's either JSESSIONID aware or can be tuned to > work with Lift's feature that re-writes URLs in such a way that it's easy to > have a load balancer send the requests back to the specific server that > houses the Lift session. > > > The fact that > > form processing can happen without inspecting GET/POST params or > > dealing with data that needs to life longer than a standard request > > cycle is pretty neat, but it raises questions about horizontal > > scalability. Where is the session data stored? > > In the app server where the session was initialized. > > > If it is in-memory by > > default, are there any best practices for sharing session data across > > application servers, or is the recommended solution to use load > > balancer affinity? > > The latter. > > With all this being said, I have significant operational experience with the > highest volume RoR powered site. A quad-core Intel/AMD box running Lift > could have handled all of its traffic. So, unless you're expecting to have > significantly more traffic than Twitter... unless you're site is saturating > a gigabit ethernet card, you can run it on a single server with Lift. > > Thanks, > > David > > > > > Ikai > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
