A>Нужно предоставить доступ через HTTPS к плюсовой библиотеке. Посоветуйте, пожалуйста, оупенсурсный web-server, заточенный специально под это. Под заточкой имеется в виду, например, такая схема: описываешь интерфейс на каком-то DSL (типа IDL), генерируешь из него имплементацию веб-сервера и хедер для имплементации интерфейса, имплементируешь интерфейс по хедеру, компилируешь имплементацию веб-сервера и имплементацию интерфейса, запускаешь имплементацию веб-сервера, подсовываешь ей имплементацию интерфейса.
Здравствуйте, Alekzander, Вы писали:
A>Нужно предоставить доступ через HTTPS к плюсовой библиотеке. Посоветуйте, пожалуйста, оупенсурсный web-server, заточенный специально под это. Под заточкой имеется в виду, например, такая схема: описываешь интерфейс на каком-то DSL (типа IDL), генерируешь из него имплементацию веб-сервера и хедер для имплементации интерфейса, имплементируешь интерфейс по хедеру, компилируешь имплементацию веб-сервера и имплементацию интерфейса, запускаешь имплементацию веб-сервера, подсовываешь ей имплементацию интерфейса.
Вот здесь говорится, что Swagger Codegen для C++ и серверной части поддерживает Pisctache и restbed. ХЗ насколько этой информации можно доверять, но можете посмотреть сами.
Здравствуйте, Alekzander, Вы писали:
A>Что-то я зашёл на https://swagger.io/specification/ и окислился. Во-первых, там вверху Try Free — я не уточнил, но ищу не просто оупенсурсное, а некоммерческое решение. Во-вторых, там половина ссылок из России не открывается.
Это не ты окислился, это swagger окислился. Правильные ссылки
Здравствуйте, Alekzander, Вы писали:
A>Так я, в целом, согласен. A>Но в этой ветке речь идёт не про веб-сервера вообще, а про организацию веб-доступа к библиотеке.
А CGI не вариант (ну т.е. просто консольное приложение)?
Или это все работает на какой-то железке?
Я бы выбрал что попроще выглядит из того что выше насоветовали.
Вот CROW вроде куда уж проще?
Здравствуйте, Alekzander, Вы писали:
A>Нужно предоставить доступ через HTTPS к плюсовой библиотеке. Посоветуйте, пожалуйста, оупенсурсный web-server, заточенный специально под это. Под заточкой имеется в виду, например, такая схема: описываешь интерфейс на каком-то DSL (типа IDL), генерируешь из него имплементацию веб-сервера и хедер для имплементации интерфейса, имплементируешь интерфейс по хедеру, компилируешь имплементацию веб-сервера и имплементацию интерфейса, запускаешь имплементацию веб-сервера, подсовываешь ей имплементацию интерфейса.
Про userver уже написали. Не получается с ходу нагуглить решение, но где-то читал что можно grpc обернуть и получить обычноый rest api.
Может для ваших нужд хватит простого grpc сервера?
Здравствуйте, Alekzander, Вы писали:
A>Здравствуйте, SaZ, Вы писали:
SaZ>>Про userver уже написали. Не получается с ходу нагуглить решение, но где-то читал что можно grpc обернуть и получить обычноый rest api. SaZ>>Может для ваших нужд хватит простого grpc сервера?
A>Я про grpc ничего не знаю, а как будет выглядеть вызов со стороны клиента? Беглый обзор пока ответа не дал. Мне нужно в 95% случаев делать вызовы из браузера и очень желательно БЕЗ ВНЕШНИХ ЗАВИСИМОСТЕЙ (в виде JS-библиотек). (Сразу скажу, это потому, что там кастомный диалект ES — он POST-запросы поддерживает, а неадаптированные библиотеки нет). Получится?
Оно то получится, но вопрос цены. В двух словах, вы на си-подобном синтаксисе пишете описание апи. А grpc+protobuf уже генерируют весь стаб (под большинство языков). По сути вам остаётся только имплементацию написать. Если нужно заморачиваться с hi load и асинхронщиной, то будет чуть сложнее. У нас был сервер на плюсах и фронт на ts/js который напрямую дёргал нужные методы (но как именно я не помню).
У них неплохая документация, можете начать тут: https://grpc.io/docs/platforms/web/basics/
Ключевое отличие grpc от rest api — под капотом всё сериализуется в бинарный формат.
Если не ошибаюсь, телеграм под капотом использует grpc, а для внешних клиентов — предоставляет http/2 api через nginx.
То есть в итоге вы можете получить .dll в которой под капотом будет grpc сервер. И уже через их механизм будет вызываться весь функционал.
Здравствуйте, Alekzander, Вы писали:
A>Да, многовато. И, главное, будет постоянно меняться. Написать не проблема, меня интересовало, почему нет из коробки.
Потому что на С++ веб-сервера пишут только "коммунисты маргиналы" (с)
Здравствуйте, bnk, Вы писали:
A>>Да, многовато. И, главное, будет постоянно меняться. Написать не проблема, меня интересовало, почему нет из коробки.
bnk>Потому что на С++ веб-сервера пишут только "коммунисты маргиналы" (с)
Здравствуйте, SkyDance, Вы писали:
S>>И? Их мало? Или более чем много? Их вообще нет?
SD>Их мало. И ничего подозрительного в этом нет.
Как человек, немного причастный к теме, могу сходу перечислить такие инструменты как Boost.Beast, Drogon, oat++, CROW (реанимированный), Simple-Web-Server, Pistache, lithium (бывший silicon framework), restbed, proxygen, cpp-netlib (он же cpp-httplib), userver, POCO, restinio. Это все проекты с множеством звезд на GitHub-е, кучей пользователей и признаками жизни. И это только на C++, я не стал включать сюда чисто Си-шные аналоги. Плюс к тому на reddit-е раз в пару месяцев люди задают вопросы о разработке бэкендов на C++ и в комментариях перечисляют и то, что указано выше, и еще всякое разное.
Так что, как по мне, для C++, который вроде как к Web-у или бэкендам никаким боком, что-то не так уж и мало встраиваемых HTTP/WebSocket серверов. Это жеж не спроста же ж.
Нужно предоставить доступ через HTTPS к плюсовой библиотеке. Посоветуйте, пожалуйста, оупенсурсный web-server, заточенный специально под это. Под заточкой имеется в виду, например, такая схема: описываешь интерфейс на каком-то DSL (типа IDL), генерируешь из него имплементацию веб-сервера и хедер для имплементации интерфейса, имплементируешь интерфейс по хедеру, компилируешь имплементацию веб-сервера и имплементацию интерфейса, запускаешь имплементацию веб-сервера, подсовываешь ей имплементацию интерфейса.
Здравствуйте, SkyDance, Вы писали:
A>>Нужно предоставить доступ через HTTPS к плюсовой библиотеке. Посоветуйте, пожалуйста, оупенсурсный web-server, заточенный специально под это. Под заточкой имеется в виду, например, такая схема: описываешь интерфейс на каком-то DSL (типа IDL), генерируешь из него имплементацию веб-сервера и хедер для имплементации интерфейса, имплементируешь интерфейс по хедеру, компилируешь имплементацию веб-сервера и имплементацию интерфейса, запускаешь имплементацию веб-сервера, подсовываешь ей имплементацию интерфейса.
SD>Аналогичный вопрос был на StackOverflow.
Что-то я зашёл на https://swagger.io/specification/ и окислился. Во-первых, там вверху Try Free — я не уточнил, но ищу не просто оупенсурсное, а некоммерческое решение. Во-вторых, там половина ссылок из России не открывается.
Здравствуйте, so5team, Вы писали:
S>Swagger Codegen для C++ и серверной части поддерживает Pisctache и restbed.
Спасибо большое.
А нет ли чего-нибудь менее универсального? Это, конечно, здорово, что я смогу в будущем из того же файла с описанием имплементировать сервер на PHP Но по опыту, за это придётся платить возможными проблемами с конкретным енд-поинтом (restbed'ом). Было бы лучше, если бы это был конкретный веб-сервер на C++ со специально для него написанными тулзами генерации, а не тулзы генерации подо всё на свете. И генерировать документацию мне не надо. И JS-клиент генерировать тоже.
Меня бы даже устроило что-нибудь совсем простенькое, если бы всё было сделано на макросах (названия методов и параметров превращались бы и в строки для веб-сервера, и в класс C++).
Здравствуйте, Alekzander, Вы писали:
A>А нет ли чего-нибудь менее универсального?
Не в курсе. Мне не доводилось слышать про генерацию обработчиков HTTP-точек входа для встраиваемого в C++ сервера. Вроде как большинству достаточно наличия аналога Express-JS и все.
Единственное, что у нас спрашивали (а мы как раз сделали в свое время встраиваемый в C++ HTTP-сервер), так это генерацию из Swagger-а для нашего сервера.
Из современного модного и молодежного посмотрите на drogon, oat++, реанимированный crow и userver. Это вроде бы то, что претендует на более-менее высокий уровень. Хотя в дополнению к этому еще три-четыре альтернативы можно назвать, но про генерацию стабов для сервера я не слышал
Здравствуйте, bnk, Вы писали:
A>>Что-то я зашёл на https://swagger.io/specification/ и окислился. Во-первых, там вверху Try Free — я не уточнил, но ищу не просто оупенсурсное, а некоммерческое решение. Во-вторых, там половина ссылок из России не открывается.
bnk>Это не ты окислился, это swagger окислился. Правильные ссылки
bnk>https://www.openapis.org/
bnk>https://openapi-generator.tech/
оффтоп, но что меня поражает во всей этой вакханалии — для Ады они серверный генератор сделали, а для самого популярного языка программирования (JS/TS) — нет. Это как вообще?
Здравствуйте, so5team, Вы писали:
A>>А нет ли чего-нибудь менее универсального?
S>Не в курсе. Мне не доводилось слышать про генерацию обработчиков HTTP-точек входа для встраиваемого в C++ сервера. Вроде как большинству достаточно наличия аналога Express-JS и все.
Это из другого проекта, который пробрасывает плюсовую имплементацию API в JS. Так вот, хотелось бы то же самое, но на уровень веб-сервера. Как можно заметить, тут дублируются имена для регистрации и имплементации (уж не помню почему), но это легко лечится.
Вот это было бы идеально.
S>Из современного модного и молодежного посмотрите на drogon, oat++, реанимированный crow и userver. Это вроде бы то, что претендует на более-менее высокий уровень. Хотя в дополнению к этому еще три-четыре альтернативы можно назвать, но про генерацию стабов для сервера я не слышал
A>class Library : public Webserver<Library>
A>{
A>...
A> BEGIN_FUNCTION_MAP
A> FUNCTION_2("getModules", getModules)
A> FUNCTION_1("offerResult", offerResult)
A> FUNCTION_1("requestSearch", requestSearch)
A> FUNCTION_0("getUserName", getUserName)
A> END_FUNCTION_MAP
A> json::value getModules(json::value folder, json::value sort) const;
A> json::value offerResult(json::value result);
A> json::value requestSearch(json::value query);
A> json::value getUserName();
A>};
A>
Вы можете наколхозить это сами с любым фреймворком, который может разобрать вам query-string на отдельные составляющие (например, посредством эмуляции Express-JS).
A>Судя по всему, придётся взять какой-нибудь Mongoose и напедалить FUNCTION_MAP самому.
Как человек, которому довелось работать в C++ном проекте с Си-ным CivetWeb, могу лишь заметить, что если хочется подосрать проекту, то задействование чисто-сишной либы в C++ном коде -- это верный путь.
Здравствуйте, so5team, Вы писали:
S>Вы можете наколхозить это сами с любым фреймворком, который может разобрать вам query-string на отдельные составляющие (например, посредством эмуляции Express-JS).
Готового, то есть, нету?
S>если хочется подосрать проекту, то задействование чисто-сишной либы в C++ном коде -- это верный путь.
А в чём проблема? Я так не делал, но в одном проекте у нас использовался сишный sqlite, и, вроде, ничего страшного не случилось.
Здравствуйте, Alekzander, Вы писали:
S>>Вы можете наколхозить это сами с любым фреймворком, который может разобрать вам query-string на отдельные составляющие (например, посредством эмуляции Express-JS).
A>Готового, то есть, нету?
У вас же в примере нужно не просто взять параметр №1 из query-string и отдать в обработчик, но еще и нужно этот параметр каким-то образом превратить в json::value, а потом еще и возвращенный json::value следует превратить в какое-то сериализованное представление и отдать это представление с соответствующим content-type и пр. Не думаю, что какой-то из встраиваемых C++ных фреймворков настолько заморачивается. Может в userver есть какие-то вещи для превращения входящих значений в что-то нужное прикладному коду. Не знаю, здесь чукча не читатель.
S>>если хочется подосрать проекту, то задействование чисто-сишной либы в C++ном коде -- это верный путь.
A>А в чём проблема?
Как правило, в C++ных фреймворках уже есть все нужное для нормального управления ресурсами. Например, request передается в обработчик в виде shared_ptr, что позволяет безопасно с ним работать. Тогда как в чистом Си будут голые указатели по которым хрен поймешь владеющий ли он или нет, можно ли его сохранять, как его освобождать при сохранении и т.д., и т.п. Плюс в C++ном коде может быть больше основанных на типизации проверок и все это будет защищать о разных неприятных ошибок.
Но, бывают разработчики, которых чисто-Си-шные макароны не пугают, терпения и внимания у них с избытком.
Здравствуйте, so5team, Вы писали:
S>У вас же в примере нужно не просто взять параметр №1 из query-string и отдать в обработчик, но еще и нужно этот параметр каким-то образом превратить в json::value
Это был код из проекта, где в C++ приходило значение из скрипта, а движок скрипта ЗНАЛ, что это за тип (типизация хоть и динамическая, но строгая). Поэтому и json::value. Тут же надо аргумент выковыривать из запроса, поэтому, соответственно, ожидается просто строка. Ну, можно при маппинге (в макросах FUNCTION_N) задавать тип, к которому требуется приведение, и отдавать его в конструктор json::value. Или просто всегда делать вызовы TryParse() в конструкторе json::value, дабы определить тип. (Предполагается, что json::value — тип, идущий в комплекте с веб-сервером).
>а потом еще и возвращенный json::value следует превратить в какое-то сериализованное представление и отдать это представление с соответствующим content-type и пр.
Разве? Клиент (в моём случае предполагается зашитый в ресурсы html + js) выполнит запрос. Что бы я ни вернул в json::value из функции-имплементации, оно уйдёт к клиенту — в соответствии с названием — как json-строка. Там нигде не нужен никакой кастомный content-type, только стандартный application/json.
>Не думаю, что какой-то из встраиваемых C++ных фреймворков настолько заморачивается.
Вот это меня и удивляет. В документации к тому же Mongoose написано, что это типичное решение для embedding'а в разные маломощные приборы (упоминается STM32), чтобы ими дистанционно управлять с веб-панели. Очевидно же, что юз-кейс такой же, как у меня: клиент (скорее всего из JS) посылает запросы, которые должны быть превращены на стороне прибора в вызов C++-ной функции. Почему это не сделано? Я что-то неправильное и нетипичное хочу?
Здравствуйте, Alekzander, Вы писали:
>>а потом еще и возвращенный json::value следует превратить в какое-то сериализованное представление и отдать это представление с соответствующим content-type и пр.
A>Разве? Клиент (в моём случае предполагается зашитый в ресурсы html + js) выполнит запрос. Что бы я ни вернул в json::value из функции-имплементации, оно уйдёт к клиенту — в соответствии с названием — как json-строка. Там нигде не нужен никакой кастомный content-type, только стандартный application/json.
Откуда встраиваемому универсальному HTTP-серверу знать, что у вас там именно application/json, а не text/plain или еще что-нибудь?
>>Не думаю, что какой-то из встраиваемых C++ных фреймворков настолько заморачивается.
A>Вот это меня и удивляет. В документации к тому же Mongoose написано, что это типичное решение для embedding'а в разные маломощные приборы (упоминается STM32), чтобы ими дистанционно управлять с веб-панели. Очевидно же, что юз-кейс такой же, как у меня: клиент (скорее всего из JS) посылает запросы, которые должны быть превращены на стороне прибора в вызов C++-ной функции.
Откуда форумчане должны узнать, что у вас прибор на маломощном устройстве?
Под термином "встраиваемый HTTP-сервер" или "встраиваемый C++ фреймворк" мной понимается HTTP-сервер, который встраивается в приложение. А не работает отдельно и общается с приложением через какой-то IPC.
A>Почему это не сделано?
ХЗ, может и сделано. Мы в своем инструменте сделали то, что нам было нужно. И нет, нам такое было не нужно.
Подозреваю, что авторы других подобных инструментов сделали то, что было нужно им.
Уж простите, что не знаю возможности всех двух-трех десятков подобных библиотек для Си и C++.
vsb>оффтоп, но что меня поражает во всей этой вакханалии — для Ады они серверный генератор сделали, а для самого популярного языка программирования (JS/TS) — нет. Это как вообще?
Есть, конечно. Мы им даже пользуемся (typescript'овым).
Здравствуйте, so5team, Вы писали:
S>Откуда встраиваемому универсальному HTTP-серверу знать, что у вас там именно application/json, а не text/plain или еще что-нибудь?
Когда? Когда зарегистрированная функция из FUNCTION_MAP отработала? Я бы сделал так: в этот момент пусть он всегда проставляет application/json, а вот если функция с подходящим названием не найдена — вызывает универсальный обработчик, в котором я сам выберу нужный content-type. Как и полагается при работе с универсальным HTTP-сервером.
>>>Не думаю, что какой-то из встраиваемых C++ных фреймворков настолько заморачивается.
A>>Вот это меня и удивляет. В документации к тому же Mongoose написано, что это типичное решение для embedding'а в разные маломощные приборы (упоминается STM32), чтобы ими дистанционно управлять с веб-панели. Очевидно же, что юз-кейс такой же, как у меня: клиент (скорее всего из JS) посылает запросы, которые должны быть превращены на стороне прибора в вызов C++-ной функции.
S>Откуда форумчане должны узнать, что у вас прибор на маломощном устройстве?
А я такое разве говорил где-то? Я говорил, что это типичный юз-кейс по словам авторов Мангуста. А для такого юз-кейса логично сделать простой маппинг запросов на вызовы C++. Что нужно и мне (но по другой причине).
Здравствуйте, SkyDance, Вы писали:
A>>Готового, то есть, нету?
SD>На С++ вообще довольно странно писать такие вещи, как Swagger/OpenAPI web server.
Мне, ещё раз, нужно сделать доступ к API C++-ной библиотеки через HTTPS. Задача в этом.
Просто я изначально предположил, что было бы удобно описать интерфейс на отдельном языке, а потом 1) сгенерировать из него плюсовый хедер и 2) скормить веб-серверу вместе с указателем на имплементацию. Наверное, именно поэтому мне и предложили Swagger/OpenAPI.
Теперь я думаю, что это была плохая идея. Хорошая идея — сделать классический function map, пример которого я привёл. Другой пример был в MFC. Да таких примеров много, на самом деле. Осталось найти пример в области веб-серверов, и задача будет решена.
Здравствуйте, SkyDance, Вы писали:
A>>Мне, ещё раз, нужно сделать доступ к API C++-ной библиотеки через HTTPS. Задача в этом.
SD>Может, проще будет взять какой-нибудь Питон, C# или Java, и через него высунуть? А библиотеку подключить через FFI.
По-моему, ещё проще руками написать FUNCTION_MAP. Если не найду готовый.
Здравствуйте, Alekzander, Вы писали:
S>>Откуда встраиваемому универсальному HTTP-серверу знать, что у вас там именно application/json, а не text/plain или еще что-нибудь?
A>Когда?
Это к вам вопрос: когда у вас появляется знание о том, в каком формате отдавать результат.
Задача встроенного HTTP-сервера принять запрос, отдать вам какой-то объект request с параметрами этого запроса, получить от вас какой-то объект response и затем корректно передать содержимое этого response клиенту.
HTTP-сервер понятия не имеет в какой момент у вас появляется response и когда вы этому response скажете какой тип данных в нем будет находиться.
A>Когда зарегистрированная функция из FUNCTION_MAP отработала?
Вы так носитесь с этим FUNCTION_MAP, что хочется спросить: а зачем она вам? У вас счет точек входа идет на сотни?
A>Я бы сделал так: в этот момент пусть он всегда проставляет application/json, а вот если функция с подходящим названием не найдена — вызывает универсальный обработчик, в котором я сам выберу нужный content-type. Как и полагается при работе с универсальным HTTP-сервером.
То, что вы описали не имеет отношения к "универсальному HTTP-серверу", т.к. универсальный HTTP-сервер должен позволить пользователю принимать/отдавать что угодно: хоть картинки, хоть видео-файлы, хоть XML, хоть json, хоть yaml, хоть черта лысого.
>>>>Не думаю, что какой-то из встраиваемых C++ных фреймворков настолько заморачивается.
A>>>Вот это меня и удивляет. В документации к тому же Mongoose написано, что это типичное решение для embedding'а в разные маломощные приборы (упоминается STM32), чтобы ими дистанционно управлять с веб-панели. Очевидно же, что юз-кейс такой же, как у меня: клиент (скорее всего из JS) посылает запросы, которые должны быть превращены на стороне прибора в вызов C++-ной функции.
S>>Откуда форумчане должны узнать, что у вас прибор на маломощном устройстве?
A>А я такое разве говорил где-то?
Ага. Выделил жирным в ваших же словах.
A>А для такого юз-кейса логично сделать простой маппинг запросов на вызовы C++.
Здравствуйте, so5team, Вы писали:
S>Как человек, которому довелось работать в C++ном проекте с Си-ным CivetWeb, могу лишь заметить, что если хочется подосрать проекту, то задействование чисто-сишной либы в C++ном коде -- это верный путь.
вот не соглашусь. Сам работал с mongoose в С++ проекте. Мне понравилось. Нет RAII, нет строгой типизации, но нет и исключений и поведение библиотеки более предсказуемое. В общем чистый спор о фломастерах.
Хотя когда я использовал mongoose я просто накидал свой С++ враппер над ним.
Здравствуйте, bnk, Вы писали:
A>>Да, многовато. И, главное, будет постоянно меняться. Написать не проблема, меня интересовало, почему нет из коробки.
bnk>Потому что на С++ веб-сервера пишут только "коммунисты маргиналы" (с)
Так я, в целом, согласен.
Но в этой ветке речь идёт не про веб-сервера вообще, а про организацию веб-доступа к библиотеке.
Здравствуйте, SaZ, Вы писали:
SaZ>Про userver уже написали. Не получается с ходу нагуглить решение, но где-то читал что можно grpc обернуть и получить обычноый rest api. SaZ>Может для ваших нужд хватит простого grpc сервера?
Я про grpc ничего не знаю, а как будет выглядеть вызов со стороны клиента? Беглый обзор пока ответа не дал. Мне нужно в 95% случаев делать вызовы из браузера и очень желательно БЕЗ ВНЕШНИХ ЗАВИСИМОСТЕЙ (в виде JS-библиотек). (Сразу скажу, это потому, что там кастомный диалект ES — он POST-запросы поддерживает, а неадаптированные библиотеки нет). Получится?
Но по опыту, за это придётся платить возможными проблемами с конкретным енд-поинтом (restbed'ом). Было бы лучше, если бы это был конкретный веб-сервер на C++ со специально для него написанными тулзами генерации, а не тулзы генерации подо всё на свете. И генерировать документацию мне не надо. И JS-клиент генерировать тоже.
