Интересна ли платформа для разработки сайтов на C++?

Question

[Владислав Орлов]

Добрый день!
В целях получения первоначальной обратной связи, интересует Ваше мнение по поводу проекта который мы хотим начать. Для удобной критики, основные моменты разбил на пункты.

Цель проекта: сделать разработку быстрых и высоконагруженных веб-сервисов быстрой и удобной

1.) Проект про которой идет речь, является веб-платформой, написанной на C++11 (+ Boost), подключаемая к веб-серверу через FastCGI.
2.) Для роутинга предполагается иметь возможность изменять его в runtime (без изменения кода платформы и т.д.) через изменение конфига роутинга.
3.) Контроллеры привязанные предлагается писать на скриптовом языке (не трогая C++, компилируя там и т.д.), например на LUA
4.) Основной функционал предполагается распространять в пакетах, которые содержат: миграции, shared library с логикой, основные шаблоны для пакета, assets и т.д.
5.) Шаблоны на DTL (Django Template Language)

Заранее, спасибо!

UPD1:
Отказались от Boost в пользу микро библиотек (под определенную задачу). Отказались от Lua в пользу более гибкой настройки правил роутинга.

Comments

[Алексей]

скажите а шаблонизатор у вас уже готов? Мне как раз нужен был чуть более сложный шаблонизатор чем plustache =). Не думали драбатывать уже имеющиеся проекты наподобие https://github.com/vinipsmaker/tufao ?

[sitev_ru]

"в пользу более гибкой настройки правил роутинга"... можно поподробнее?

[Владислав Орлов]

sitev_ru: В конфиг файле роутинга можно будет указать ассоциацию между запрошенным путем и парой "контроллер"-"действие". Запрошенный путь можно будет регуляркой разобрать. Такое уже есть в одном фреймворке https://github.com/ChicagoBoss/ChicagoBoss/blob/ma... .

Что мы хотим еще добавить по сравнению с ChicagoBoss: перенести разбор методов (GET, POST, DELETE и т.д.) в конфиг, добавить поддержку модулей (у нас они есть), добавить возможность делать редирект прям в конфиге.

[sitev_ru]

Владислав Орлов: Когда можно будет потестировать первую версию вашей платформы?

Answer 1

[dyadyaSerezha]

Я бы начал с перечня недостатков текущих решений и объяснения, как эти недостатки исправит предлагаемое решение. Иначе все бессмысленно.

Comments

[Владислав Орлов]

Одни из популярных решений сейчас это сайты на PHP, Ruby (RoR), Node.js, Python (Django), Java.

С первым завсегдатаем сравнивать нечего, совсем разные цели. Тут выигрыш сразу за нашем решением, т.к. в runtime PHP не умеет работать (не нужно мне показывать костыли типа phpDaemon )

Любимый руби... Хороший язык, легко подойдет для создания прототипов и не очень сильно нагруженных проектов. Из минусов у него: низкое быстродействие, кушает много памяти.

Node.js давно не следил за ним. Да все круто, NPM там, плюшки всякие, но выходить на высокие нагрузки с костылями, чтобы работало в несколько потоков (все ядра задействовать) - не серьезно. Ну и мне лично страшно писать на нем код, где неявное приведение типов с динамическими типами вытворяют фокусы из-за твоей не внимательности.

Python. К сожалению против сказать ничего не могу, не пользовался. Но вот оценить шаблоны в Django смог - мне понравились, правда не на всю мощь. Писали небольшой сервис на Erlang (ChicagoBoss) в свое время.

Java ну вот это достойный конкурент. Много Enterprise-решений сделано на нем. Холивары до сих пор идут кто круче. Но вот явный минус для высоконагруженных систем у Java это память.

Резюмируя, хочу сказать, что в сравнениях по памяти и вычислениям тут явно Си++ является одним из лучших в своем роде. Основным минусом у него конечно остается: высокий порог вхождения, скорость разработки небольшая, мало удобств ("синтаксический сахар")

[dyadyaSerezha]

Владислав Орлов: про память как недостаток Java, не очевидно далеко. Где эти упоминаемые "сравнения"? Кстати, теперь и C#/.Net открытым стал... И как правильно заметили выше, где анализ проблем производительности для реально крупных проектов? Может, там 10-кратное изменение скорости исполнения языка влияет на 10% производительности системы?

Answer 2

[Армянское Радио]

Из хорошего: возможно, это будет работать быстро. Еще быстрее это будет, если вы выбросите долой boost и FastCGI, написав собственный веб-сервер. Гулять так гулять, как говорится.

Если же это все ради забивания гвоздей мелкоскопом, используйте Hiphop PHP или kPHP. Они транслируют всеми любимый PHP в C++, а затем и в so.

Comments

[Владислав Орлов]

Boost за борт (смысла нет тащить такую либу из-за пары заголовков) :) FastCGI пока останется, свой веб-сервер писать для автономности пока смысла нет - потеря времени. Давно "любимый язык" остается на компьютере в офисе, лишний раз с ним сталкиваться нет желания.

Answer 3

[Sergey Lagner]

Лично мне был бы интересен подобный проект, если open source то мог бы поучаствовать даже.
Однако, некоторые моменты вызывают сомнения.
1. Зачем FastCGI? Это лично мое IMHO, но он уродлив и отжил свое. Может лучше писать свой сервер(на базе libuv или boost asio, например). Если от FastCGI избавляться не хотите, то советую посмотреть на решение програмистов из yandex'а Fastcgi-Daemon. Чем ваше будет лучше?
2. DTL как формат или вы python будете встраивать? Просто это странно, зачем проседать в производительности здесь, когда существуют плюсовые шаблонизаторы, Mustashe как пример
3. В скриптовых контроллерах как-то не особо смысл вижу.
У меня была идея реализовать что-то подобное nodejs express на плюсах со слоеной архитектурой и асинхронными обвязками для сокетов, БД и т.д.
Для сопутствующих файлов использовать qrc из Qt, тогда деплоиться это будет как одна монолитная so'шка.
Правда пока это так и осталось на уровне идеи...

Comments

[Владислав Орлов]

1.) Да согласен, что уродлив чем-то и стар уже, но он вполне годно работает. Первоначальный выбор обусловлен инфраструктурой у нас на продакшене, а именно балансировщиком и набором важных переменных окружения от него. Думаю из общего мнения, фича в виде standalone платформы будет неплоха и будет развиваться. Библиотека стандартная: www.fastcgi.com
2.) Вдохновил в свое время https://github.com/erlydtl/erlydtl - хотим также
3.) Да тоже передумали, после небольшого брейншторма, в пользу более настраиваемых правил роутинга

Ну у нас упор идет на модульность логики, объединяемые в конфигурации для распространения... (Привет 1C!)

[Армянское Радио]

Владислав Орлов: В свое время мне удалось вообще всю логику убрать в базу данных Firebird в виде хранимых процедур и триггеров. Учитывая приятный момент в виде распараллеливания запросов, можно сделать все очень отзывчивым. Но у меня клиент на C++/Qt. Хотя на ту же идею можно и веб-морду навесить.

Answer 4

[Алексей Елецкий]

Не актуально.

1. Основная задержка при обработке запросов к страницам сайтов идёт на обращение к сторонним сервисам (базам, кэшам и так далее), а не на роутинг, поэтому выигрыш в производительности будет не таким большим, как кажется (и хочется).
2. Действительно тяжёлые вычислительные вещи и так пишутся на C++, легко встраиваясь в инфраструктуры традиционных веб-ЯП.
3. Затраты на содержание команды C++/Lua программистов выше, чем на PHP/Perl/Python/Ruby + пару лишних серверов, если понадобится. Плюс, за этими языками ещё и инфраструктура гигантская стоит. Сроки разработки тоже не в пользу С++ программистов.
4. Уже есть Go — он занимает как раз ту нишу, в которую вы целите.

Резюме — не стоит. Это не ниша C++ — этот старый благородный ЯП имел достаточно времени, чтобы её занять и не занял.

Comments

[AxisPod]

1. Грубо говоря, выигрыша вообще не будет
2. Ну в тот же PHP встроить тот еще геморой
3. Качество кода программистов, содержание которых обходится дешевле содержания разработчиков C++ ниже плинтуса.

[Владислав Орлов]

1. Данные предварительно можно подгружать в память при возникающей необходимости. После чистить. В этом и есть плюс runtime над интерпретацией. А семейство Си более выгодно смотрится над остальными языками по возможностям манипулирования с памятью.
2. Согласен, такое и мы делали, что уж скрывать... Честно? Поддерживать проект на нескольких языках сложнее.
3. Порог вхождения естественно у нас намного выше... Снижать? Смысла нет, многие дешевые программисты понятия не имеют о алгоритмах, анализах вычислительной сложности - с такими нам не по пути :)
4. Пользовались, чем-то особенным не впечатлил.

[Алексей Елецкий]

Владислав Орлов
1. Совсем странная мысль. Во-первых сейчас мало что действительно интерпретируется. Во-вторых, разграничение на рантайм/интрепретацию, мягко говоря, странное и необоснованное. Рантайм — это когда программа выполняется, а как — это уже совершенно другой вопрос. Ничто не мешает подгружать данные и в других языках. Только это не решение всех проблем, а частный случай. Существенного выигрыша по памяти всё равно не будет.
3. Знание алгоритмов и таких понятий как вычислительная сложность слабо коррелирует со знанием ЯП. Это одно из очень популярных заблуждений C++ программистов, от него надо избавляться.

Answer 5

[sitev_ru]

Представил, что было бы, если бы я занялся этой задачей...

1.) Проект про которой идет речь, является веб-платформой, написанной на C++11 (+ Boost), подключаемая к веб-серверу через FastCGI.

Интересно... Веб-программисту дал бы простенькие классы, для работы с этой платформой

3.) Контроллеры привязанные предлагается писать на скриптовом языке (не трогая C++, компилируя там и т.д.), например на LUA

Я против LUA. Только С++!!! )))

5.) Шаблоны на DTL (Django Template Language)

Наверное, слишком сложно... я бы взял HTML + внутри переменные вида: {var}

Чтобы вашей команде было интереснее, я уже тоже взялся за подобный проект... Можно объединить усилия! )

Comments

[Зелимхан Бельтоев]

Я против LUA. Только С++!!! )))

Для таких задач, где нужен интерпретируемый ЯП, С++ не лучшее решение =)

Answer 6

[Константин Китманов]

Если бизнес-логика будет все равно написана на Lua, то откуда скорость?

Comments

[Владислав Орлов]

основная логика идет на модели, которые реализованы на C++

[Константин Китманов]

Владислав Орлов: если у вас основная логика в моделях, то у вас т.н. "тощие контроллеры", т.е. логики в них мало и меняться они будут редко. Тогда зачем их делать на Lua?

[Владислав Орлов]

От LUA передумали в пользу продвинутого конфигурирования роутинга

Answer 7

[AxisPod]

1. Уже есть готовые решения, которые дают доступ через CGI, FastCGI, Socket и т.д., в чем отличия от существующих?
3. Какой тогда смысл вообще в C++? Сетевая работа в скриптовых языках и так уже написана на C++.
2. Если делать всё же на контроллеры C++, то в рантайме роутинг не имеет смысла.
4. Ну обычно все заводят подобное под свою инфраструктуру или не заводят, это последнее о чём стоит думать на данном этапе
5. Будете реализовывать свой полноценный шаблонизатор? Почему бы не взять готовое решение и допилить? Либо подразумевается использование python?

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

Answer 8

[tzlom]

Такие вещи уже существуют, даже статьи на хабре были, однако не взлетело.

Comments

[Владислав Орлов]

Пруф-линк

Answer 9

[Виктор]

А вы по cppsp слышали?

Comments

[Владислав Орлов]

Нет. Сейчас ознакомился, я как понимаю проект более не развивается... Ахтунг! Лицензия GNU GPLv3 !!! Это означает, что использовать такое мы у себя уже не сможем, да и у многих клиентов.