[web-devel] Re: consolidating Haskell's web-framework scene

[Michael Snoyman]

On Mon, Mar 15, 2010 at 9:07 AM, Dmitry Belayev <rumata-estor at nm.ru> wrote:

> Compile-type checking can be very helpful and it is Haskell's strong side.
>
> But what about hot code swapping? In working web application it is often
> convenient to update some part of application without disturbing connected
> users. It's strong side of Erlang, but what about Haskell?
>
>
That's definitely a good point. My current deployment uses lighttpd/CGI to
server the application, along with a development system running on 3000.
Here's my workflow:

1) Develop on local system using simple-server.
2) Push changes to development system. Who cares about a little downtime
there.
3) When everything works, pull changes into the production repo.
4) Compile everything with -Wall -Werror.
5) Copy templates, static files and CGI binary in one fell swoop to the
production directory.

So this is really a solution outside of Haskell. I believe Turbinado used
some features for dynamically compiling code, but I prefer this kind of
approach in general.

If I was during a standalone server approach, one possibility for production
deployment might be:

1) Run the production server on port 3001 (or anything else). Set up
iptables to forward port 80 to port 3001. (I do this already).
2) When I want to make a production change, start a *new* production server
on port 3002.
3) Adjust iptables to port forward to 3002.
4) Next time around, switch back to 3001.

For the record, I think iptables forwarding is probably the safest way to
run an application on a privileged port.

Michael Snoyman wrote:
>
>> And part 2:
>>
>> Yesod is still missing a model layer. This is a project that I will most
>> likely be doing myself, since it will need to be designed to integrate very
>> closely with Yesod, but I'll mention some of the design ideas here. (By the
>> way, Chris Eidhof has a package on Github called Basil which looks very
>> interesting here.)
>>
>> 1) I want to use YAML quasi-quoting to define the models.
>> 2) I don't want a super-complex "object relational mapping"; Haskell is
>> already much closer to the relational level than an OO language.
>> 3) Utilize IO thunks (ie, lazy IO loading) so that we don't need to load
>> everything into memory at the beginning.
>> 4) Not tied down to SQL *or* in-memory databases. It should support both
>> of those, but *also* support a system that is usable even in a CGI setup.
>> I'm contemplating now a database that uses multiple directories/files and
>> uses append-only to avoid concurrency issues.
>>
>>
>> Compile-time checking of templates would be great. The Bravo package looks
>> interesting, but I'm a little dubious about the approach used. I think
>> something based on typeclasses might be a bit more nimble. Once again, tight
>> integration with the model system I theoretically design would be nice.
>>
>>
>> So, in summary of a much-too-long e-mail, let's not bother trying to get
>> everyone to agree on One Framework. Happs has its place, Yesod has its
>> place, and I know others are using Loli and probably Kibro. (I'm not sure if
>> anyone every got started with Turbinado.) However, we can raise the bar for
>> *all* packages simultaneously by making a more solid ecosystem of Haskell
>> web packages available that any framework can cherry-pick from.
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> web-devel mailing list
>> web-devel at haskell.org
>> http://www.haskell.org/mailman/listinfo/web-devel
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100315/61a0f8b0/attachment.html