Lapis: сайт на Lua в конфигах Nginx

[kay]

> А ещё LuaJIT может привязать функции и структуры C на стороне Lua (без написания привязок на C):
При условии, что C функция использует неблокирующие операции. В противном случае код будет работать в блокирующем режиме.

[starius]

Совершенно верно! Хороший иллюстрация применительно к веб-прокси: можно было импортировать блокирующие функции из libcurl и делать HTTP-запрос с их помощью. Без сомнения, это привело бы к блокировке потока. В первую очередь в C имеет смысл выносить вычисления, а не работу с сетью.

[Shoonoise]

Это вообще основная проблема модуля lua-nginx — выстрелить себе в ногу, не представляя тонкости реализации, очень просто.

[iSage]

Применительно к nginx-lua сеть вообще не имеет смысла выносить в ffi, протсо потому, то все уже сделано до нас в виде ко-сокетов nginx.

[starius]

del

[AterCattus]

Мне MoonScript не понравился своим синтаксисом: он как-то крайне «переслащен». А исходники Lapis написаны как раз именно на нем, *.lua код генерится уже из них, и он нифига не хороший и понятный.
Еще генерация nginx.conf шаблона видится излишней — ведь было бы достаточно проставить в нужных местах content_by_lua_file и подобные.

offtopic. Я в мае-июле экспериментировал с исходно lua-минифреймворком, ориентирующимся на скорость, много основополагающего наваял, но потом поменял работу и пока как-то не до него)

[starius]

У меня был опыт переписывания небольшого сайта с Lua на MoonScript и я тоже не восторге от MoonScript, в нём бы убрать половину возможностей. Поначалу мне казалось, что MoonScript — это «питон без двоеточий», но обилие собак, восклицательных знаков и обратных слешей в коде убручает. Совершенно верно, что он переслащён. У Lapis и MoonScript один и тот же автор.

Однако Lua в составе исходников Lapis, кажется, допиливается напильником после генерации из MoonScript.

К примеру, привязка к GET и POST происходит неэквивалентным способом на Lua и MoonScript:

Lua:

app:post("/geturl", function(self)
  -- code
end)

MoonScript (часть класса):

["/geturl"]: respond_to {
  POST: =>
    -- code

В документации есть отдельные главы Введение для MoonScript, и Введение для Lua. Самое главное, что Lapis можно полноценно использовать вообще без MoonScript.

[ZyXI]

В neovim одно время использовался moonscript. Если забыть про прочие проблемы (малое число разработчиков, синтаксис, который многим не нравится, отсутствие в ряде дистрибутивов), то мы напоролись на довольно странную проблему: тесты с moonscript уходят в бесконечный цикл, со сгенерированным lua — нет. В связи с тем, что проблема была не единственная и фактически не приводимая к простому примеру, то особо разбираться никто не стал: просто сказали, что все тесты теперь на lua (раньше сначала говорили, что все тесты на moonscript, но из-за сопротивления разработчиков разрешили lua и moonscript; теперь только lua).

[mva]

А я, вот, пишу тут код ну Resty-template с полноценными темплейтами с возможностью инлайнить lua (а-ля SSI). И как-то, если честно, понравилось намного больше мунскриптов-ляписов :)

[Mithgol]

Эта затея выглядит весьма небезынтересно.

Некоторое сомнение, правда, вызывает вот эта картинка:

Так как движок Node.js сам по себе способен реализовывать неблокирующий ввод и вывод (evented I/O), то ставить nginx между Node и клиентом не очень, наверное, рационально. (Проще говоря, ну что такое может nginx, с чем Node не справится при помощи пары-тройки-другой модулей? Вопрос не очень риторический.)

Предвижу ещё, что тот подход, при котором скрипты работают непосредственно в рамках цикла событий (event loop) на сервере, действительно обретёт популярность, да вот только наиболее популярным будет сочинение таких скриптов не на Lua для nginx, а на JavaScript для Node. Это предвидение опирается на необыкновенную популярность джаваскрипта (основного языка клиентской части Всемирной Паутины) и, кроме того, на наличие множества готовых модулей для Node — на наличие таких пакетов с открытым исходным кодом, которые npm установить может.

(В роли сервера, например, будет выступать, скорее всего, не голый движок Node, а что-то вроде Express поверх него — и это ещё по меньшей мере.)

[AterCattus]

>>что такое может nginx, с чем Node не справится
работать быстрее?

[thunderspb]

>>что такое может nginx, с чем Node не справится
эм, таким образом можно сказать и про php, он же умеет в сервер. и зачем обвешивать nodejs кучей модулей, когда, ИМХО, лучше повесить старый, надежный nginx как фронтенд перед nodejs сервером. тот же load balance, кеш, статику, логи лучше отдать nginx.

[apelsyn]

Справедливости ради надо сказать что ветка nodejs 0.11.xx поддерживает генераторы, которые умеют приостанавливать выполнение кода с помощью оператора yield.

С помощью библиотеки co ваш код будет выглядеть так

var co = require('co'), 
    request = require('co-request');

co(function* () {
  var result = yield request('http://www.whatever.com/my.csv'); 
  console.log("Got body: " + result.body);
})();

Для обработки ошибок можно использовать try/catch

[MyGodIsHe]

Сколько памяти ест? Хочется что-то динамическое и чтоб кушал 0-5 метров. Самое то для простеньких штук. Голый html хорош, но главная проблема в отсутствие шаблонов (как include и extends в jinja).

[starius]

Памяти ест примерно как просто nginx. На моем несложном сайте при тестировании ботами было 1-2 мегабайта памяти и почти нулевая загрузка процессора.

В Lapis предусмотрено использование шаблонов etlua, которые позволяют исполнять любой код на Lua и предусматривают экранирование переменных. Ещё можно подключать подшаблоны (аналог include). Аналога extends, кажется, нет. Шаблоны etlua похожи на PHP, что имеет свои плюсы и минусы. Удобно, что для чего-то особого не нужно ваять свой тег, как в django, но опасно, что шаблон может в принципе что угодно. В небольших проектах преимущества такого подхода перевешивают недостатки, без сомнения.

[MyGodIsHe]

Спасибо, звучит интересно, попробую.

[motienko]

можно и совсем голый html, например, так.

[xmm]

Смотрим вкладку «Multiple queries» теста и что видим — lapis нижней части списка и с кучей ошибок. Что же это? Неправильно приготовленная корутина с тяжелым запросом или это неисправимо?
Зато вперед выходит дарт с монгой )

[starius]

На том же тесте с другим оборудованием Lapis уже в середине списка и без ошибок. В чем дело, сказать не могу. Есть только догадка, что в том тесте могла плохо работать связка nginx-postgres. На той же странице, где Lapis-postgres в конце списка, openresty-mysql занимает неплохое место.
Дарт звучит интересно, надо посмотреть.

[DenVdmj]

Для тех кто любит Lua, и Node: есть luvit (Lua + libUV)
github.com/luvit/luvit