Немогу не поделиться своими выводами об изучении нескольких новых технологий в Perl и в Web программировании. Немного предистории.
Я сам программирую динамические веб сайты (CGI) только на Perl. Никогда не использовал PHP. Это не только потому, что я фанат Perl, но и дань эффективности — под Perl много модулей, много возможностей, и при грамотном подходе сайты на Perl будут работать быстрее PHP — ведь Perl код после компиляции хранится в памяти в виде байт кода (типа «Пи кода» кода в Pascal). А если знаешь Perl, то и разработка может идти гораздо быстрее.
До недавнего времени я использовал технологию Apache + mod_perl + Embperl, а сам внешний WWW сервер имел фронтенд -Apache + mod_accel либо еще лучший вариант — nginx (оба — реализуют проксирование). Лет 8 назад это было отличным решением, когда я начал использовать эту технологию. Но сейчас она устарела и сложна в использовании.
Сейчас я всем программерам на Perl, пишущим приложения под Web, очень рекомендую обратить внимание на следующие технологии в Perl, которые, несомненно эффективнее и проще, чем вышеуказанная связка:
- PSGI технология, а также ее реализация через модули Plack
- Starman — perl сервер, с режимами pre-fork, контроля количества процессов и многое другое. Вообщем, почти как apache.
- Dancer — отличное решение для реализации своих PSGI приложений, но с более простым программированием.
Сейчас немного подробнее
PSGI — недавно придуманный стандарт для Perl, который реализует простой и понятный программисту подход — вместо написания CGI скриптов и всей этой ваши с передачей параметров серверам и т.п.., очень умный человек (Tatsuhiko Miyagawa) придумал (правда взяз за основу наработки из Python) простой подход — любое приложение (будь то скрипт или группа скриптов) оформляется в виде обычной perl функции, которая чётко принимает и возвращает определенные параметры: принимает ссылку на хеш, в котором есть и заголовки HTTP, и служебные заголовки (вместо старых в CGI переменных окружения), а возвращает ссылку на массив из трех элементов: HTTP ответ, ссылку на массив заголовков ответа и ссылку на массив данных (HTTP BODY). Просто и со вкусом! Причем, можно возвращать и ссылку на код функции для реализации stream потоков. То есть в PSGI можно реализовать любой вид сервера — простой, отдающий потоковые данные (типа видео, например), либо удерживающее соединение (Comet технология). Но и это не все. Прелесть такой структуры функции PSGI в том, что одна функция может вызывать другую PSGI, но при этом делающее что-то своё. То есть другими словами — стек вызова. Называется это — middleware. А Plack служит клеем — имеет в своем составе сервис функции для формирования такого стека.
И, конечно же, если подумать, нужен сам сервер, который будет принимать TCP соединения, парсить заголовки и формировать хеш для PSGI, вызывать его и отдавать ответ. И таких серверов написано уже много. Один из них — Starman. Он, практически, выполняет те же функции, что выполняла бы связка Apache + mod_perl, только гораздо эффективнее, так как он проще, и нет тех «костылей», которые были приделаны в apache & mod_perl для их функционирования.
А что же делает Dancer? Он называется типом Frameworks в терминологии Plack. Он для сервера Starman работает как PSGI, но вы сами пишите на perl через предоставляемые Dancer-ом функции, которые облегчают вам жизнь. Dancer сам парсит входные данные от Starman, формирует их в удобный вид для обработки в perl и также формирует обратные заголовки и данные. К тому же, Dancer может работать без Starman — он имеет свой простой вебсервер. Также, раз Dancer может работать как PSGI функция, его можно вызывать из под любого сервера Plack типа, а также на нем можно написать свои middleware. Вообщем, тут вам как ваша фантазия и профессионализм подскажет.
Есть вероятность, что Dancer вытеснит Catalyst?
Не знаю — я не изучал Catalist 🙂
Но мне, чем я больше изучаю Dancer — все больше и больше начинает мне нравится (точнее, связка Dancer + Starman)