С++ Web Services

[recoder]

Возникла идея в рабочей системе вообще отказаться от интерпретируемых языков. Статику отдавать через Apache, клиента сделать на статическом JavaScript, а динамику отдавать через FastCGI из своего C++ приложения в XML/JSON.

В теории идея выглядит вполне работоспособной. Однако мысль о том, что придётся переизобретать маленькую роту велосипедов, которые в Rails/Django вылизывались годами, меня очень смущает. Гугление уже существующих решений (и их обсуждений типа - раз два три четыре) дало такие примеры:

CppCMS: похоже, довольно полная библиотека для написания приложения. Всё как у взрослых: кое-какие routes, контроллеры, темплейты+views+шкуры и всё прочее. Немного смущает что, как и другие фреймворки, у них свои строки, массивы и прочие базовые классы. Но в целом - кажется приемлемо.

Wt: любопытная widget-ориентированная библиотека для написания веб-систем. Оригинальная, но уж очень самобытная. А к самобытным системам ни Dojo не прикрутишь, ни программистов потом не найдёшь. Плавали - знаем.

TreeFrog: похоже на попытку аккуратного портирования Rails на плюсы, но результат непонятный: проект молодой, документация почти несуществующая.

ffead: занятная штука, судя по всему написанная сумасшедшим Java-программистом, который почему-то начал писать на C++. Посмотреть конечно прикольно, но не брать же это в production.

CPP SERV: уже другие безумные Javaнцы переписывали на C++ - на этот раз servlets. Однако года три назад вылечились и бросили это дело.

Есть ещё кучка библиотек помельче для разработки мини-сервисов: Klone, PoCo, NanoGear, REST CGI. Но с ними опять придётся выстраивать собственно архитектуру с самого начала. А не хочется.

Выходит, особенного изобилия веб-приложений на C++ не наблюдается. И начинают закрадываться сомнения - может быть, миллионы мух не могут ошибаться, тысячи программистов уже пробежали этот марафон по граблям и разбрелись кто куда?

Вот, сижу теперь, думаю... Записываться в экстремалы с такой системой или плюнуть и откопать PHP?

Comments

[larubin.livejournal.com]

Имхо идея правильная.

Я вот только не понял, зачем тебе мегафреймворки для отдачи данных в ххмль/джсон?

[recoder]

Какие-то фреймворки всё равно придётся использовать. Иначе - руками парсить заголовки, руками и регэкспами разбирать урлы, и т.д. И получится очередной свой велосипед, но уже на плюсах.

[vanxant.livejournal.com]

Так а задача какая?
Просто проверить параметры, взять данные из базы селектом и завернуть в json/html? Ну так в этом случае 80%-90% времени будет работать база, да и алгоритмы декорирования в том же пыхапе до блеска отлажены.
Или у вас там какая-то сложная математика, которую считать долго, и нужны какие-то хитрые алгоритмы? Ну и всё равно, джедаи в этом случае советуют считать на плюсах и складывать данные в базу в memory-таблицу. А отдавать апачу всё равно предназначенным для этого инструментом.

[recoder]

Задача - накрыть бизнес-логику, написаную на C++, двумя штуками: Web UI и Web API. Так что это не обязательно просто выборки из базы.

[Андрей (from livejournal.com)]

Посмотрите на CAS от Rambler http://cas.havoc.ru/ на нем, вроде как, их почта работает (сам не смотрел, c++ - не мое =) )

[netspyder.livejournal.com]

> Статику отдавать через Apache
если проект не маленький, можно посмотреть на связку NGinx+Apache/PHP или вообще NGinx+PHP-FPM.
я для интереса поднял связку NGinx+Apache+PHP-FPM, так он летает куда шустрее, чем на Apache+FastCGI, на котором живут остальные сайты.
а с последней - вынес статику (картинки статей) на паре вордпрессов в субдомен на NGinx, тоже весьма неплохо.

[avnik.livejournal.com]

Апачь в описаной схеме лишний совсем.

[netspyder.livejournal.com]

пардон, "поднял связку NGinx+Apache+PHP-FPM" читать "поднял связку NGinx+PHP-FPM" =)

[avnik.livejournal.com]

Переходим к второму этапу ;)
Есть джанго/райлс/пирамида/whatever, нахрен нужен этот пхп вообще?

[netspyder.livejournal.com]

ох и натрахался я с джанго, *простите за мой французский*))
с этими яйцами и прочими прелестями. 100500 раз объяснял этой скотине, этому жЫвотному, куда класть свои яйца. несколько раз он их пытался откладывать в разные места совершенно без каких-либо очевидных причин, а сколько велосипедов на эту тему, ухх. но починить таки удалось, каким-то телепатическим способом. =)
Ruby тоже веселая штука, милион версий, не дай Боже поставишь что-то поновее со старым - все, велосипед не едет. но тоже удалось полечить, указал в файле версии, которые подгружать. телепатия рулит))

[avnik.livejournal.com]

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

[netspyder.livejournal.com]

и в /root и в /tmp и куда-то там еще. вы не поверите сколько раз вопрос о яйцах попадается в гугле)
PYTHON_EGG_CACHE
python-eggs
вот по этим словам можете поискать.

[avnik.livejournal.com]

не верю.

PS Впрочем допускаю, что делающий make install от рута идиот, потому что не осилил инструкцию даже до середины.

[netspyder.livejournal.com]

делал не от рута. хотя это достаточно странно, весь софт на FreeBSD от рута ставится))

[avnik.livejournal.com]

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

[netspyder.livejournal.com]

не силен в питоне, не знаю, что такое билдаут, пардон)
просто клиент попросил поставить такой велосипед, пришлось ставить))

[avnik.livejournal.com]

Ну для питонизмов есть два традиционных способа:
1 -- virtualenv (типа чрута, но исключительно для интерпретатора -- влияет на его пути поиска, и яйцеустановку), бонус -- изоляция от "системных" питонопакетов
2 -- buildout -- строит песочницу с наполнением по формальному описанию, чем-то издалека похоже на bsd порты. Полной изоляции не делает, но может быть засунуто в virtualenv. Зато гарантирует возспроизводимость (особенно если ты прикопал за угол все скачаное в процессе).

Туториал по билдауту от автором джанги
http://jacobian.org/writing/django-apps-with-buildout/http://jacobian.org/writing/django-apps-with-buildout/
(впрочем телега тоже устарела, но как отправная точка сгодится)

http://buildout.org -- родная документация, которой хер знает сколько лет, внутри исходников она поактуальнее.

Если есть вопросы, могу ответить.

[netspyder.livejournal.com]

спасибо, пока не нужно, но прикопаю ссылки на всякий случай)

[recoder]

Увы, Apache надолго прописался в системе по соображениям совместимости и выкидывать его пока нельзя. Даже за прокси ставить не хочется - проблем с производительностью пока нет, а риски что что-нибудь отвалится - всегда имеется.

[bluedrag]

Посмотри на OKWS, на котором написан OKCupid: http://www.okcupid.com/about/technology

[recoder]

Спасибо, посмотрю. Но на первый взгляд это как Wt - большой самобытный фреймворк.

[mpak666.livejournal.com]

А зачем такие сложности в будущем при отладке, поддержке и развитии потом этого С++ веб-продукта?

Если стоит Apache то почему бы не посмотреть на mod_perl скорость просто идеально вшитая внутрь Apache кишков, отлаживать легче, хотя надо быть и аккуратнее с "мусором", но всё же разработка быстрее будет в разы, имхо.

А не хочется связываться с perl, полно интрументов например в ruby и ниже rails уровня, как sinatra или прям на голый rack садиться.

[recoder]

Идея - минимизировать количество технологий используемых в продукте. Чтобы во-первых, унифицировать весь инструментарий, во-вторых, чтобы проще было ротировать программистов между командами, и т.д.

[kpeo-y3k.livejournal.com]

с самого старта фреймворка работаю с CppCMS - из всего перечисленного сейчас кажется самым перспективным. единственная проблема - ненулевое вхождение в тему.

как JSON-RPC вполне рабочий фреймворк, для этого есть отдельный вид асинхронного приложения "cppcms::rpc::json_rpc_server" (http://cppcms.com/wikipp/en/page/cppcms_1x_json_rpc)

сейчас как раз пишу для него фронтенд для более простой и быстрой разработки собственных приложений (типа Kotti в Pyramid Python-проекта Pylons), надеюсь уже скоро открою для тестирования :)

[omas.livejournal.com]

Выросла ли идея во что-нибудь? Или так идеей и осталась?

[recoder]

Выросла-выросла! Пришлось правда написать кучу кода почти что с нуля. Как-нибудь соберусь с мыслями и опишу текущие результаты. Но пока времени нет - надо систему допиливать...

[omas.livejournal.com]

У меня сейчас в голове похожая идея про комплекс прикладных Web приложений на C++.
Целей несколько:
- Производительность, снижение требований к инфраструктуре
- Качество, C++ позволяет лучше структурировать код, чем остальные языки Web разработки, за исключением Java C#
- Кросс-платформенность, чем не может похвастаться C#
- Наличие огромного массива С++ приложений, который можно переиспользовать.

[recoder]

Мне всё-таки кажется, что для веб-сервисов C++ - не лучший выбор. А приведённые выше цели - мне видятся как раз проистекающими из той самой "преждевременной оптимизации", которая корень всех программистских зол.

Если нет внешних ограничений на язык реализации веб-приложения - надо таки-брать Ruby, Python или хотя бы Perl с соответствующим фреймворком и прикручивать бизнес-логику на любом языке. Скорость начальной разработки будет выше на порядок, причём по нескольким причинам. Во-первых, веб - это строки, а строки в плюсах - это совсем не центровое в отличие от скриптовых языков. Во-вторых, тыщи готовых модулей под скриптовые фреймворки с большой вероятностью позволят за считаные часы наваять работоспособный прототип. В-третьих, тестирующие фреймворки опять же за короткое время помогут зафиксировать внешние требования в наборах тестов всех уровней.

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

[omas.livejournal.com]

Возможно оно так и есть. С другой стороны требования к инфраструктуре в последнее время просто заоблачные.
Тестовые фреймворки в зависимости от того, к какому месту их подключать: либо не зависят от языка реализации, либо для С++ их тоже достаточно.
А вот практически полное отсутствие готовых библиотек для разработки Web на С++, действительно, настораживает.