Comments 21
> А ещё LuaJIT может привязать функции и структуры C на стороне Lua (без написания привязок на C):
При условии, что C функция использует неблокирующие операции. В противном случае код будет работать в блокирующем режиме.
При условии, что C функция использует неблокирующие операции. В противном случае код будет работать в блокирующем режиме.
del
Мне MoonScript не понравился своим синтаксисом: он как-то крайне «переслащен». А исходники Lapis написаны как раз именно на нем, *.lua код генерится уже из них, и он нифига не хороший и понятный.
Еще генерация nginx.conf шаблона видится излишней — ведь было бы достаточно проставить в нужных местах content_by_lua_file и подобные.
offtopic. Я в мае-июле экспериментировал с исходно lua-минифреймворком, ориентирующимся на скорость, много основополагающего наваял, но потом поменял работу и пока как-то не до него)
Еще генерация nginx.conf шаблона видится излишней — ведь было бы достаточно проставить в нужных местах content_by_lua_file и подобные.
offtopic. Я в мае-июле экспериментировал с исходно lua-минифреймворком, ориентирующимся на скорость, много основополагающего наваял, но потом поменял работу и пока как-то не до него)
У меня был опыт переписывания небольшого сайта с Lua на MoonScript и я тоже не восторге от MoonScript, в нём бы убрать половину возможностей. Поначалу мне казалось, что MoonScript — это «питон без двоеточий», но обилие собак, восклицательных знаков и обратных слешей в коде убручает. Совершенно верно, что он переслащён. У Lapis и MoonScript один и тот же автор.
Однако Lua в составе исходников Lapis, кажется, допиливается напильником после генерации из MoonScript.
К примеру, привязка к GET и POST происходит неэквивалентным способом на Lua и MoonScript:
Lua:
MoonScript (часть класса):
В документации есть отдельные главы Введение для MoonScript, и Введение для Lua. Самое главное, что 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.
В neovim одно время использовался moonscript. Если забыть про прочие проблемы (малое число разработчиков, синтаксис, который многим не нравится, отсутствие в ряде дистрибутивов), то мы напоролись на довольно странную проблему: тесты с moonscript уходят в бесконечный цикл, со сгенерированным lua — нет. В связи с тем, что проблема была не единственная и фактически не приводимая к простому примеру, то особо разбираться никто не стал: просто сказали, что все тесты теперь на lua (раньше сначала говорили, что все тесты на moonscript, но из-за сопротивления разработчиков разрешили lua и moonscript; теперь только lua).
А я, вот, пишу тут код ну Resty-template с полноценными темплейтами с возможностью инлайнить lua (а-ля SSI). И как-то, если честно, понравилось намного больше мунскриптов-ляписов :)
Эта затея выглядит весьма небезынтересно.
Некоторое сомнение, правда, вызывает вот эта картинка:
Так как движок Node.js сам по себе способен реализовывать неблокирующий ввод и вывод(evented I/O), то ставить nginx между Node и клиентом не очень, наверное, рационально. (Проще говоря, ну что такое может nginx, с чем Node не справится при помощи пары-тройки-другой модулей? Вопрос не очень риторический.)
Предвижу ещё, что тот подход, при котором скрипты работают непосредственно в рамках цикла событий (event loop) на сервере, действительно обретёт популярность, да вот только наиболее популярным будет сочинение таких скриптов не на Lua для nginx, а на JavaScript для Node. Это предвидение опирается на необыкновенную популярность джаваскрипта (основного языка клиентской части Всемирной Паутины)и, кроме того, на наличие множества готовых модулей для Node — на наличие таких пакетов с открытым исходным кодом, которые npm установить может.
(В роли сервера, например, будет выступать, скорее всего, не голый движок Node,а что-то вроде Express поверх него — и это ещё по меньшей мере.)
Некоторое сомнение, правда, вызывает вот эта картинка:
![[Node.js позади nginx]](https://habrastorage.org/getpro/habr/post_images/130/131/587/1301315875a9c972e1b98be3f772db94.png)
Так как движок Node.js сам по себе способен реализовывать неблокирующий ввод и вывод
Предвижу ещё, что тот подход, при котором скрипты работают непосредственно в рамках цикла событий (event loop) на сервере, действительно обретёт популярность, да вот только наиболее популярным будет сочинение таких скриптов не на Lua для nginx, а на JavaScript для Node. Это предвидение опирается на необыкновенную популярность джаваскрипта (основного языка клиентской части Всемирной Паутины)
(В роли сервера, например, будет выступать, скорее всего, не голый движок Node,
>>что такое может nginx, с чем Node не справится
работать быстрее?
работать быстрее?
>>что такое может nginx, с чем Node не справится
эм, таким образом можно сказать и про php, он же умеет в сервер. и зачем обвешивать nodejs кучей модулей, когда, ИМХО, лучше повесить старый, надежный nginx как фронтенд перед nodejs сервером. тот же load balance, кеш, статику, логи лучше отдать nginx.
эм, таким образом можно сказать и про php, он же умеет в сервер. и зачем обвешивать nodejs кучей модулей, когда, ИМХО, лучше повесить старый, надежный nginx как фронтенд перед nodejs сервером. тот же load balance, кеш, статику, логи лучше отдать nginx.
Справедливости ради надо сказать что ветка nodejs 0.11.xx поддерживает генераторы, которые умеют приостанавливать выполнение кода с помощью оператора yield.
С помощью библиотеки co ваш код будет выглядеть так
Для обработки ошибок можно использовать try/catch
С помощью библиотеки 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
Сколько памяти ест? Хочется что-то динамическое и чтоб кушал 0-5 метров. Самое то для простеньких штук. Голый html хорош, но главная проблема в отсутствие шаблонов (как include и extends в jinja).
Памяти ест примерно как просто nginx. На моем несложном сайте при тестировании ботами было 1-2 мегабайта памяти и почти нулевая загрузка процессора.
В Lapis предусмотрено использование шаблонов etlua, которые позволяют исполнять любой код на Lua и предусматривают экранирование переменных. Ещё можно подключать подшаблоны (аналог include). Аналога extends, кажется, нет. Шаблоны etlua похожи на PHP, что имеет свои плюсы и минусы. Удобно, что для чего-то особого не нужно ваять свой тег, как в django, но опасно, что шаблон может в принципе что угодно. В небольших проектах преимущества такого подхода перевешивают недостатки, без сомнения.
В Lapis предусмотрено использование шаблонов etlua, которые позволяют исполнять любой код на Lua и предусматривают экранирование переменных. Ещё можно подключать подшаблоны (аналог include). Аналога extends, кажется, нет. Шаблоны etlua похожи на PHP, что имеет свои плюсы и минусы. Удобно, что для чего-то особого не нужно ваять свой тег, как в django, но опасно, что шаблон может в принципе что угодно. В небольших проектах преимущества такого подхода перевешивают недостатки, без сомнения.
Спасибо, звучит интересно, попробую.
можно и совсем голый html, например, так.
Смотрим вкладку «Multiple queries» теста и что видим — lapis нижней части списка и с кучей ошибок. Что же это? Неправильно приготовленная корутина с тяжелым запросом или это неисправимо?
Зато вперед выходит дарт с монгой )
Зато вперед выходит дарт с монгой )
На том же тесте с другим оборудованием Lapis уже в середине списка и без ошибок. В чем дело, сказать не могу. Есть только догадка, что в том тесте могла плохо работать связка nginx-postgres. На той же странице, где Lapis-postgres в конце списка, openresty-mysql занимает неплохое место.
Дарт звучит интересно, надо посмотреть.
Дарт звучит интересно, надо посмотреть.
Для тех кто любит Lua, и Node: есть luvit (Lua + libUV)
github.com/luvit/luvit
github.com/luvit/luvit
UFO just landed and posted this here
Sign up to leave a comment.
Lapis: сайт на Lua в конфигах Nginx