writeln — шаблонная функция

все эти filter, map и тому подобные это тоже шаблонный код

как-то так

ребят, а кто уже в production vibe выпускал? ему нужен nginx например? вообще что nginx делает, кэширует html, как-то распределяет нагрузку? может кто-то разбирался как правильно развёртывать сайт на vibe?

Я не выпускал. vibed может работать и без nginx сам на 80 порту, но лучше все таки спрятать его за nginx - очень быстрая работа, раздача статики, кеширование, балансировка, работа с множественными бэкендами - вот плюшки.

Хотя если у тебя только rest api какое-нибудь без html совсем, то впринципе и нету смысла в nginx

Хотя если у тебя только rest api какое-нибудь без html совсем, то впринципе и нету смысла в nginx

У меня пока ничего))

Возможно сделать по аналогии с Django. Статику раздает nginx, а код выполняется на vibe.d?

qwe статические страницы подключать к nginx и писать их на html, а не на diet?

Я так и предлагаю. Но они одновременно не смогут на 80 порту висеть, полюбому тогда nginx будет проксировать запросы к vibed

diet это не статика, статика это то что лежит в виде файлов - картинки, голые html страницы, css стили и т.д.

ааа

вот как

т.е. vibe.d теоретически статику тоже может отдавать, но я уверен что будет делать это намного хуже чем nginx

если nginx специально для этого был сделан, то вероятнее всего

Кстати еще один веб-фреймворк есть https://github.com/putao-dev/hunt пилится активно. Пока толком не ясно чем от вайба отличается, кроме своей библиотекой для ассинхронных запросов

Я все не могу понять, а какие у тебя планируются нагрузки? Ты иногда такие вопросы задаешь, как будто у тебя будут тысячи запросов в секунду.

Кстати еще один веб-фреймворк есть https://github.com/putao-dev/hunt пилится активно. Пока толком не ясно чем от вайба отличается, кроме своей библиотекой для ассинхронных запросов

Выглядит и правда 1 в 1 как vibe.d, непонятно зачем

@chebotarevp как раз хотел посоветоваться)))) Будет максимум 1000 (в ближайшем будущем хорошо если будет 20) одновременных посетителей, но для каждого из них нужно будет производить достаточно сложные вычисления (собственно из-за них это и будет делаться на D а не на Python например) и много запросов к внешним api, возможно активное взаимодействие с frontend (как я понимаю websocket получше будет чем ajax). Может не заморачиваться пока с nginx?

websocket и ajax решают разные задачи

@qwe да?

Можешь и не заморачиваться, но для знающих людей развернуть nginx перед вайбом это час времени всего лишь

ну да, на ajax не сделать чатик к примеру

поставим вопрос другим ребром

что нельзя сделать с помощью websocket, а делается с помощью ajax?

Ну так-то ничего, websocket покрывает ajax )

какие плюсы у ajax перед websocket?

Из плюсов - ajax может работать на более старых браузерах, там где не работает websocket

ajax нужен для асинхронных запросов, websocket нужен тогда, когда надо клиенту что-то отправить не по его запросу, а по какому-то сигналу

я могу пример привести, если нужно

да, так будет лучше

с примером

ajax работает только по запросу пользователя (хм, а таймеры в js?) websocket отрабатывает сообщения, как обычный сокет (так можно же создать очередь команд от пользователя в js?)

так?

можно, но разве в jabber так сделано? Мне кажется так лучше не делать

Кстати еще один веб-фреймворк есть https://github.com/putao-dev/hunt пилится активно. Пока толком не ясно чем от вайба отличается, кроме своей библиотекой для ассинхронных запросов

а насчёт "ещё одного"... это же великолепно! как только появится какая-нибудь крутая фича рыжий зашевелится и начнёт приводить vibe в порядок))

websocket, действительно, работает по аналогу socket. Про очередить не понял, если честно

@qwe а я про jabber)))

исходя из api websocket он может только onmessage

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

хотя хз... можно же их и сразу отправлять

это в том случае, если бы send мог работать, только как ответ внутри onmessage

так что очереди лишние

Jabber я привел как пример протокола обмена сообщениями. То есть вряд ли в клиентах Jabber (pidgin например) работает таймер и по нему запрашиваются новые сообщения

@deviator секунду подождите, я Вам пример приведу

хорошо

hunt вообще мало похож на vibe

Если пользователь переходит на страничку, скажем раздел товаров, то тут нужно отправить ajax запрос. Если надо пользователю что-то надо показать и это что-то должно произойти в результате какой-то логики на сервере (backend), то тут нужны веб сокеты. Хороший пример это чат. Кто-то из пользователей отправляет сообщение в чат, об этом узнает сервер (D код) и посылает сигнал по websocket, потом на клиенте (JS код) уже надо что-то программировать.

по всей видимости там соглашения именования как в ror

@qwe 1 пользователь - 1 сокет?

или к 1 серверному сокету подключаются много клиентов?

Как хочешь так и делай, можешь с каждого клиента хоть 10 вебсокетов открыть

Сервер будет держать эти соединения, туда можно слать текст, получать текст

а как логичней? на одну задачу по сокет или на клиента?

на клиента

Логичней на клиента одно соединение, но тут встает проблема - у клиента может быть открыто несколько вкладок с твоим сайтом

Можно 1 соединение на вкладку делать

@chebotarevp мне кажется это надо решать на клиенте

ща спрошу в конфе фронтендеров)

+1

=)

ну его к чёрту... фронтэнд этот))

нанимать будем...

Вы не поняли идеи?(

да нет, понял, просто это 1 из 1000 аспектов

и он уже вызывает столько разговоров

для этого нужен отдельный человек, который в этом спец)

просто думал сейчас чуток вникнуть в это дело, чтобы уж совсем нубом не быть

Ты прав, проблем и работ там огромная куча :) Как посылать авторизационные токены через вебсокеты, как получать и обрабатывать события асинхронно, какой фреймворк взять и т.д.

изначально в этом проекте я отвечать буду за архитектуру интелектуальной системы и отчасти за алгоритмы (нейросети, классификаторы и тд), а это тоже не маленькая тема а тут ещё фронтэнд)

и изначально была идея писать на django, а модули обработки ускорять на d

но как-то потом взгляд упал на vibe и вроде там есть многое, что нужно

но это ещё будет решаться через ~20 дней

кто-нибудь уже ускорял так сайт?

но как-то потом взгляд упал на vibe и вроде там есть многое, что нужно

10 раз задумайся, там очень многого нету =)

Для веб разработки

первое, что прям не приятно, это orm

По факту это просто голый демон который умеет с http/ws работать

А так - ни нормальной шаблонизации, ни экшенов, ни контейнера, ни всяких ACL, ни генераторов админок..

По факту это просто голый демон который умеет с http/ws работать

По факту это скорее вебсервер, а не веб-фреймворк

хм

а что такое "нормальная шаблонизация"?

diet это не то?

или шаблоны через шаблоны языка это не норм?))))

кто-нибудь уже ускорял так сайт?

Мы когда имели такие сложновычислительные задачи, решали это отложенными вычислениями через очереди. В твоем случае я вижу норм вариант, когда вся система написана на скриптовом языке + JS на фронте, а тяжелые вычисления доступны по апи где-нибудь на api.projectname.com

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

А вся работа с аутентификацией/авторизацией, пользователи, бизнес логика - это на django

Олег, в качестве клиентской части Vue-JS очень рекомендую. Я хоть и не профи, но но после Ангулара он реально смотрится очень и очень хорошо

diet это не то?

Сейчас глянул документацию, оказывается diet делается как клон Jade, тогда это уже намного лучше :) Это нормальная шаблонизация

первое, что прям не приятно, это orm

Когда реализуют (еслиэто вообще произойдёт) https://wiki.dlang.org/DIP50 – будут орм не хуже линка, но это пока что мечты.. Самому уже хочется сесть за работу над компилятором, да маловато знаю

Вот еще шаблонизатор https://github.com/dymk/temple

Мы когда имели такие сложновычислительные задачи, решали это отложенными вычислениями через очереди. В твоем случае я вижу норм вариант, когда вся система написана на скриптовом языке + JS на фронте, а тяжелые вычисления доступны по апи где-нибудь на api.projectname.com

А это очень даже крутая идея

api на d, сайт на django

Мне вайбом нужно файл поймать отправленный из браузера. Какой url более идеоматичный? Пhосто /upload ?

да

А не подскажешь куда смотреть чтобы понять какая функция отправленный данные должна ловить? http://vibed.org/api/vibe.http.server/

Ищи тут http://vibed.org/api/vibe.http.server/HTTPServerRequest

файл посылается в запросе в теле сообщения

В запросе должен быть хедер со значением multipart/form-data