Фреймворк Fastcgi Container

[RPG18]

После знакомства с Slim и Mojolicious наследоваться от handler, как то не хочется. Поэтому silicon выглядит чуточку приятней.

[lpre]

Если речь идет о Web-UI или Web-API для существующего C++ приложения — да, может оказаться удобно.

[RPG18]

Но не в данном случае, т. к. требует стороннего веб сервера. Для таких случаев подходит что-то со встроенным веб сервером CppCMS, Wt и т.д.

[maydjin]

UI — очень размытое понятие. Например под os/400 с точки зрения разработчика ui пользователь представляется как файл, в который можно писать и с которого можно читать (ессно можно при этом использовать select например) :)

[lpre]

Была задача: оценить возможность создания web интерфеса для существующего приложения. Т.е. "функционал" уже есть, и он был написан на C++ задолго до этого.
Переписывание всего приложения на Ruby, nodejs или др. только из-за удобства создания web приложения не имеет смысла, так как приложение должно и дальше быть доступным на платформах Windows, Mac OS X и Linux.
Я допускаю, что fastcgi не лучший вариант для этого, однако считаю что в любом случае лучше использовать C++ для интеграции C++ приложения в web.

[IvanPanfilov]

> однако считаю что в любом случае лучше использовать C++ для интеграции C++ приложения в web.

но как же так — если мы поверх накручиваем http сервер, JSP и xml — то это типа быстрее и проще и лучше
чем просто слать бинарный поток данных через сокеты?

[lpre]

Нам недостаточно просто слать данные через сокеты. Нужны как минимум роутинг для доступа к разным частям API и поддержка параллельных запросов с тред-пулом. А это уже и есть сервер «накрученный поверх». Мы не стали изобретать свой, а взяли готовый Fastcgi Daemon и немного доработали его под свои нужды. Поддержка XML конфигов взята из него полностью. Транслятор шаблонов страниц в C++ код взят из POCO с небольшими доработками. В результате мы получили 100% интеграцию с нашими приложениями, упростив сопровождение.

Тоже самое можно было бы сделать, взяв за основу какой-либо готовый легковесный HTTP сервер (опять же на C++ для лучшей интеграции). Поэтому я и сказал, что допускаю, что fastcgi не лучший вариант для этого.

[AxisPod]

На чем основано предположение, что ответ на C++ будет выдан быстрее? Сам по себе C++ позволяет конечно добиться многого, но чтобы это было действительно так, нужен довольно порядочный опыт. Да и не думается мне, что все возьмутся сами писать серваки с мультиплексированием запросов, с неблокируемым вводом-выводом, да при этом еще и асинхронные.

[GamePad64]

На boost.asio можно особо не напрягаясь написать асинхронный неблокирующий сервер.

[monah_tuk]

Можно. А можно написать так, что он будет внезапно "дедлочится" (видел раз шикарный длинный while (true) со sleep(1) в обработчике). Всё делать с умом нужно. Асинхронность, даже с Asio, не особо простая штука.

[AxisPod]

Ну дык напишите. Если взять за основу их примеры, то очень долго потом будете искать фантомные баги, утечки и т.д. и это при условии, что они почти ничего не умеют. На деле пилить придется ну очень долго.

[beduin01]

http://vibed.org/ в разы для этой задачи удобнее

[highpower]

Даже не верится, что этому поделию ровно 10 должно на днях исполниться :)

[bolk]

Ты ради этого расчехлил аккаунт на «Хабре»? :) Да ладно, всё циклично же. Кто вот поверит, что все эти NoSQL были ещё до реляционных баз? Или что на JS на сервере можно было программировать во времена Перла? А сейчас это всё — передовые технологии.

[IvanPanfilov]

«Один пацан писал все на C++, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.»

[lpre]

В оригинале, если не ошибаюсь, про JavaScript было? Или сейчас всё с ног на голову перевернулось, и теперь уже за C++ на сервере в дурку забирают? :-)

[lpre]

Я уже ответил несколько раз лично Вам чем нас не устраивает JavaScript и почему мы используем C++.
«Holy war C++ vs. JS» устраивать не собираюсь, поэтому приводить иных аргументов не буду.

[lpre]

Ответы на 1 и 3 лично вам:
habrahabr.ru/post/280814/#comment_8838182
habrahabr.ru/post/280814/#comment_8838298
habrahabr.ru/post/280814/#comment_8840166

2: Я и не утверждал, что вы к чему-либо призываете. Я несколько раз ответил вам лично почему мы используем C++. И всё… ;-)

[RPG18]

Тогда в их случае придется делать взаимодействие их приложения с сервером на котором крутится JS. Что вы предлагаете использовать для взаимодействия?

[IvanPanfilov]

шаблоны JSP, серлеты, xml зачем копировать java серверный стек если можно просто использовать java серверный стек. с java хоть глобально и надежно будет.
если б оно еще например из JSP и xml собирало С++ код. это веть идеология С++ вычислять все насколько возможно во время компиляции а не исполнения приложения.

выглядит как студенческая поделка, не осилевшего java и которому засрали голову что С++ это гарантированно быстро и высокопроизводительно.
а как пишутся настоящие высокопроизводительные сервера на с++ можно посмотреть
https://github.com/xaxaxa/workspace/
http://xa.us.to/cppsp/index.cppsp
https://github.com/stefanocasazza/ULib
http://www.techempower.com/benchmarks/

там такой адский C++ код в стиле C или вообще написано на С (nginx), а не новомодных стандартах С++ и ООП

[lpre]

Для наших числодробильных задач C++ подходит лучше чем, например, JavaScript.
К тому же приложения давно уже есть (GUI и CLI).

[lpre]

Я отвечал Вам, а Вы в том числе и о JS (node.js) упоминали (здесь).

К тому же, для наших числодробильных задач C++ подходит лучше чем Java.

[IvanPanfilov]

С++ для числодробилки — это здравая мысль.
вопрос в том — нафига тут xml, JSP, http сервлеты — реализуем серверный стек java, когда можно было просто слать бинарные данные через сокет

> К тому же приложения давно уже есть (GUI и CLI).
ну вот надо дисклеймер класными буквами в начале статьи — что это типа подход исторически сложившийся не используйте это в новых проектах.
а то люди могут неправильно понять и подумать что это новая штука для высокопроизводительных серверов на C++

[lpre]

Мы его и не писали. Мы взяли готовый и доработали его под свои нужды. Подозреваю, что сложность доработки сравнима со сложностью написания модулей к ноде (которую мы никогда не использовали и совсем не знаем).

[lpre]

Из двух первых ссылок:

All the code i've ever written since grade 11; also includes some forward-ported code from grades 8 and 9

«выглядит как студенческая поделка» ;-)

«Адский код» нам тоже не нужен.

[IvanPanfilov]

ну да, из ваших комментов я уже понял что статья не про производительность, а про переиспользование с++ кода

а «Адский код» — это жертва которую всегда придется отдавать ради производительности.