Какова экосистема для веб-разработки Haskell?

Вдохновленный этим вопросом и недавним , мне интересно что связано с веб-разработкой Haskell.

  • Есть ли какие-либо веб-фреймворки или шаблоны для Haskell?
  • Как будет размещаться сайт Haskell, есть ли подходящие веб-серверы?
  • Является ли Haskell слишком сложным для обычного быстрого процесса разработки и прототипов, часто используемого в веб-разработке?
  • Есть ли примеры существующих веб-приложений Haskell?

Ответ 1

Прежде всего, отказ от ответственности: я никогда не делал веб-разработки Haskell, поэтому я не говорю по опыту.

Если вы посмотрите на веб-категорию в Hackage, есть много пакетов, связанных с веб-сайтом.

Я думаю, что большинство веб-приложений Haskell запускаются на настраиваемом сервере (возможно, используя Apache mod_proxy или IIS Advanced Request Routing в качестве внешнего интерфейса). Однако есть также некоторые привязки FastCGI.

Самая известная инфраструктура веб-сервера Haskell/framework/datastorage Happstack, что интересно по нескольким причинам, наиболее очевидным является то, что это сохраняет все свое состояние в памяти и не использует реляционную базу данных.

Еще один более поздний веб-серверный интерфейс - hack, о котором я мало что знаю, кроме того, что 1 минута учебника выглядит интересным.

В Haskell есть еще много веб-серверов/фреймворков, но эти два - это те, что я знаю о верхней части головы.

Ответ 2

Я сделал настоящие веб-приложения для производства в Haskell. Вот стек, который я использовал:

для генерации Html. Это немного забавный синтаксис, но по крайней мере у вас есть лямбда-абстракция. для подключения бэкэнд к , выполняя веб-службу.

Все веб-приложение представляет собой одну программу haskell, скомпилированную в собственный код ghc. Я написал код, чтобы выполнить маршрутизацию запроса (и обратную маршрутизацию) вручную.

Ответ 3

Я использовал Happstack для создания простого webapp/webservice для нашей локальной интрасети.

  • Он хранит данные в памяти с журналом транзакций для восстановления (стандартный с Happstack). Вы не найдете SQL в коде где угодно.
  • Нет шаблонов. То, что обычно делалось с шаблонами, я делаю в Javascript. Просто получите данные в формате JSON и поместите их в DOM.

Есть только 169 строк кода Haskell, все в Main.hs, которые определяют сервер. Остальное - Javascript для презентации, а некоторые Python для тестирования.

Это открытый исходный код, вы можете проверить его на GitHub и, возможно, использовать его как отправную точку.

Ответ 4

  • Существуют ли какие-либо веб-фреймворки или шаблоны Haskell?

Существует много веб-фреймворков. Посмотрите в категории Web: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:web

Для шаблонов HStringTemplate является лидером бренда: http://hackage.haskell.org/package/HStringTemplate

  • Как будет размещаться сайт Haskell, есть ли подходящие веб-серверы?

Статически связанные двоичные файлы, запускающие собственный веб-сервер (например, happstack-server или один из других веб-серверов Haskell), двоичные файлы Haskell, разговаривающие с Apache,... почти каждая комбинация, о которой вы могли подумать.

  • Является ли Haskell слишком сложным для обычного быстрого процесса разработки и прототипов, часто используемого в веб-разработке?

Нет. И вы получите более сильные гарантии, что приложение не ошибочно благодаря системе типов.

  • Есть ли примеры существующих веб-приложений Haskell?

hpaste - простая демонстрация для happstack. Tupil.com весь бизнес - это веб-приложения Haskell. В прошлом году Deutsche Bank дал интервью в CUFP на своих внутренних веб-фреймворках Haskell (на основе happstack).

Ответ 5

Во-первых, черт возьми, если эта ссылка "дело" не была одной из самых забавных вещей!

Теперь, когда я отправил ответ по другой ссылке, я не думаю, что на веб-сайте Haskell много чего происходит. У вас есть Happstack и, возможно, несколько других фреймворков, которые, похоже, никуда не денутся. Затем у вас есть FastCgi.

Если вам нравится, то FastCgi, вероятно, достаточно хорош для большинства ваших потребностей. Большинство клиентов, как мне кажется, действительно не имеют проблем с масштабами (и, кроме того, достаточно хороши для людей Ruby, правильно).

Если FastCgi - это не ваша скорость... ну, возможно, рыскания или подъем (Эрланг и Scala, соответственно) заслуживают внимания.