Проблема в том, что у С/С++ самая лучшая инструментальная инфраструктура (бэкэнд, оптимизирующий компилятор, LTO, DCD, LLVM и вот это вот все). Все остальные находятся на уровне если не детсада, то строительного техникума и курят в сторонке. Альтернативы ей нет и не предвидится.
Но фронтэнд, который для человеков, он не просто эстетически ужасен, он какой-то просто человеконенавистнечиский. Простые вещи делаются до предела странными, сложными и многословными конструкциями, это никак не способствует чтению и верификации кода. И делается почти всегда не как у всех, что особенно печально.
Про то, что изначально все базовые примитивы принципиально сделаны не так как у Swift, Kotlin, Java и пр. наследников С++ это понятно (типа кто там первый был и мог подумать как на самом деле надо было), но что мешало уже сделать потом нормально? Зачем тянуть в века это замшелое и посредственное говно мамонта под названием библиотека SGI STL, зачем-то называя ее стандартом? Она даже хешмапы делает плохо, есть более быстрые и удобные. И почему именно эту библиотеку в стандарты двинули, почему нельзя взять любую другую, которая хотя бы строки и контейнеры будет делать в стиле Java (к примеру), и в camelStyle нотации имен? Сколько можно этими подчеркиваниями мучаться?
100500 способов 32 битное целое называть - это вообще зачем? Почему нельзя один раз всем сказать, что со следующего стандарта int это всегда знаковое 32 битное целое и успокойтесь там уже со своим PDP-11, сидите в своем музее на на старом стандарте, вас никто не трогает.
И кому реально так сильно впилась эта обратная совместимость, все равно же без флагов --std= в реальной жизни не обойтись? Хочется писать в духе С++98, ну и отлично - вот вам песочница и отдельные .deb/.rpm со "стандартными" библиотеками, не плачьте.
А вот небезопасные штуки доступа к памяти можно было вполне запретить по дефолту, в равной степени как и принудительную верификацию диапазонов и прочих выходов за границ обязать делать - это все вполне можно было через опцию флажками компилятора привинтить, да и стандартную библиотеку давно пора переписать с нуля, начиная с спецификаций интерфейсов, тут никакой Америки нет. Кому прям очень надо там для какого CRC32 алгоритма - старый стандарт или unsafe флаги в помощь.
Но мир видимо решил проявить упорство в своем безумии и все надежды возложить на весьма странных парней из Rust (как минимум странных своими чумовыми названиями - все эти трейты, крейты, опять не похожий на всех синтаксис), дескать они уж точно знают как надо. Наивность веры в Rust просто невероятно поражает, учитывая, что им пока не удалось ничего более внятного, чем несколько относительно неплохих библиотек для веб микросервисов написать и сильно ограниченно их популяризовать (и то, даже на C++ есть библиотеки и побыстрее, и в целом покруче).
Альтернатива где? Не на Swift же переходить? Хотя поневоле задумаешься, они там уже и на UTF-8 догадались переползти, и даже начали макросы применять, не пройдет и 30 лет как совсем взрослыми станут.
фильтры и гриды - это весь твой уровень? там htmx справится.
PWA так вообще смешно :)
По теме совсем нечего сказать? Это печально (с).
Кстати, а упомянутые "фреймы" это вообще что? Это так по-молодежному frameworks уже стало принято называть? Типа как "собес" это оказывается собеседование, а вовсе не то место, где СНИЛСы выдают?
Ок, тебя попросили привести пример действительно сложных интерфейсов. В результате мы услышали про клики на свечах на SVG графиках, и увидели невнятную попытку самоутверждения демонстрацией чувства превосходства в финале.
Это вообще не спортивно. А можно было и про хитрые LOV с диалогами поиска, и про настраиваемые/сохраняемые фильтры в каких pivot или обычных гридах поговорить, для начала. И про offline mode в PWA, чтоб уж точно HTMX на лопатки положить.
Впрочем это наверное уже middle уровень, джуниорам такое не поручают? Ну и ладно, как нибудь в другой раз.
SSE/Websockets лично я не занимался, да, чятики пилил другой человек. Ну в чем там сложность-то? sectet's hash можно послать каким угодно способом, да хоть как часть пользовательских данных. В чем откровение-то?
Клики на свечу? Да, такое я тоже не делал. Дальше что?
Загуглить "Add onclick event to SVG element" и найти готовый снипет может ребенок лет семи наверное. И потом еще штук 30 снипетов на выбор, какой больше глазу приятнее будет.
Тоже мне ловля на живца, смешно. Это все задачи уровня pre-junior. Решаются правым мизинцем и половинкой гипоталамуса (и ChatGPT вполне справится), там больших ресурсов и не требуется.
Как обычно, это как? Как Htmx авторизовывает sse/websocket/ соединение? (По тз показываем графики только авторизованным клиентам и сессионная кука может стать не валидной, забаненной, как обработать на htmx такие случаи?).
Зачем? auth_token куки шлет браузер. Можно и без кукисов, в HTMX есть возможность дописывать произвольные request headers, но зачем усложнять?
Про невалидную куку не совсем понятно. Как обрабатывать на HTMX ошибки от сервера? Да как угодно, можно заново редиректить на страницу авторизации (сервер инициирует редирект клиента), или на стороне браузера можно перехватывать какие 403/404. Можно и так и так, как угодно. Там вообще нет никаких ограничений и навязываемых подходов, только новые дополнительные к HTML5/CSS3/JS6 фичи, которые можно использовать, можно не использовать (правда автор странно любит и поддерживает даже и IE11, но шутки по этому поводу оставим, у него видимо это личное).
Дальше что происходит? От sse/ws приходят только json? Чей код апдейтит графики и свечи? Ваша писанина как-то при входящем data вызывает bar.update()? или htmx умеет апдейтить графики автоматически ?
В смысле умеет? HTMX штатно сам умеет по клику или какому еще событию получить от сервера HTML код, встроить его куда сервер скажет, при случае вызвать указанный сервером JS или и вовсе сделать какой redirect/page reload. А что сверху - всегда можно ловко донавернуть самому в нужных местах разными способами, плюс расширения всякие готовые.
Там нет ничего военного - всякими разными подходами можно отработать действия пользователя и выслать на сервер request, куда записать тоже что угодно, и получить от сервера ответ - по дефолту один кусок HTML и target element id (но можно и много кусков, и много target), скрипты потом обработчиками вызывать, события получать/заново слать, и т.д. и т.п. Там нет ограничений, в отличие от. Полная свобода. Там только одно ограничение - нет обязательности в React/Vue/Angular и любого иного натужного OpinionWare в зависимостях.
Только htmx.min.js и браузер с его базовым функционалом, этого уже достаточно для полноценного SPA. А дальше можно самому развивать и декорировать куда захочется.
получится ему навесить свои хендлеры на чужие html элементы постоянно меняющиеся, обновляющиеся?
Элементарно. Один из способов - регистрируются custom events, на них вешаются обработчики. Сервер шлет этот самый event, обработчики делают что им там нужно, получив нужные данные через event параметры. И это лишь один из способов.
Может стоит документацию почитать и примеры поизучать? Они там очень прикольные, читаются легко, задорно и весело, в отличие от React/Vue/Angular тягомотины. Первая глава и эссе особенно заставляют прям задуматься о безумии этого вашего корпоративного софтостроения и не только.
Я же правильно понимаю ваш посыл, графики и свечи постоянно рендерить на серверных мощностях и отдавать готовый html в браузер клиентам?
Вообще не правильно. В самом начале сервер просто "рендерит" HTML на создание веб компонента для рисования графика. Благо их уже сотни готовых на любой вкус и цвет (в т.ч. и для чисто vanilla js).
Генерит или на первоначальной загрузке страницы или в момент когда пользователь кликнет на какую кнопку или закладку с "Динамика цен". Результатом обработки нажатия кнопки будет прилетевший в нужный element id этот самый HTML фрагмент с этим графиком и каким приложенным javascript кодом c данными. Lazy loading в действии. По сути гидратация через SSR, или как там в реато-SPA это сейчас называется.
И дальше как обычно - туда сюда шлем на/с сервера хоть JSONы, хоть сразу новые SVG элементы для графиков, хоть '<script></script>' на выполнение это кому как будет веселее.
HTMX это же не про "э блин, а вот теперь все снова все делаем типа только на HTML5/CSS3/NoJavascript, ну ок и вот чутка AJAX но больше нини", вовсе нет.
HTMX - это про "а вот сейчас мы элегантным, но мощным пинком выбрасываем наследие React/Vue/Angular//Svelte/Belte/Next/Nuxt/Naxt/Nixt/Nyxt../../../../../ (N=100500)xt" и начинаем жить нормальной жизнью фуллстек девелопера с уклоном в какие бухгалтерии, без выгорания на хуках и history API.
А конкретика - информационные системы типа b2b торгов, трейдинговые платформы, ИС МФЦ, АСУ, и прочие проекты из Бигтек.
Ну и? В чем проблема?
На HTMX нельзя сделать график со свечами или ордербук через SSE/WebSockets/etc в реалтайме?
Конкретнее, конкретнее пожалуйста. Я ведь тоже могу типа сильно умным прикинуться и рассказать, что на HTMX прям никак нельзя BOM процессы для сметно-кадастрового геодезического центра со спутниковым мониторингом перемещения грузовиков в реальном времени запилить, только на реакте, только на нем любимом.
Или какое CAE твердотельное моделирование механики жидких сред для спутникового коллайдера.
100 тудулистов на разных языках. Действительно, сложный графический интерфейс.
Причем тут примитивизм todo examples? HTMX это просто подход, это не законченный фреймворк-инфраструктура с темплейтами аля Wordpress или Joomla.
Это по сути просто библиотека (да, ок, для PJAX и еще кое чего).
Если сравнивать с автомобилем - это да, по сути старый двигатель, но уже нового принципа действия, не ДВС, не электродвигатели, а скорее гравицапа. Которую можно вкрутить в свой старый Долориан и получить сосем новое некое качество перемещения из точки А в точку Б.
А дописать (переосмыслить, написать заново) нужные UI компоненты и в целом шаблоны - это вполне достижимая, веселая и задорная задача на ближайшие пару месяцев, как раз теперь и повод есть.
Ну или продолжать натужно ездить на индийском Реакт/Нода автобусе, не зря же права категории D последние пять лет дружно всем отделом получали :)
И раз вы все равно генерируете код на сервере, вам и htmx /pjax /ajax не нужен. Зачем вам вообще это.
Что такое сложный проект со сложными интерфейсами? Рассказывать про over 9000 примитивных CRUD страниц не надо - из даже если и будет более 100500, то суть их примитивности (качество) от количества оных не изменится.
Тогда что такое тогда сложный интерфейс? Какой необанк по типу Тинькофф это сложный или не сложный? Озон, алиэкспресс?
Что именно там такого в этих "сложных" интерфейсах, что в принципе нельзя сделать через HTMX с небольшими вкраплениями VanillaJS и WebComponents?
Можно пример? Типа вот берем форму заказа от Али, и... ? Наверное оплату через QR код по СПБ не прикрутить, или OAuth какой, да?
Конкретика будет? Или как всегда ограничимся абстрактными пугалками вида "а вот как только у вас проект станет достаточно сложный, так сразу начнутся проблемы идемпотентности зависимостей в силу роста величины модульного зацепления" ?
Слышал звон, да не знает где он. Потому что этот же автор ноды запилил другой проект, учтя все ошибки. Ну и есть альтернативы всякие.
Звон, трезвон, альтернативы, зачем это все? Есть же "тренд", что на Javascript будет переписано тотально вот вообще все, от фронта, бека и чуть-ли не JаvascriptOS вот вот уже будет с нами. Ну и? Когда же уже будет всеобщий JS Universe?
На самом же деле это все просто от инертности мышления. В браузерах весьма изначально странный по своей природе JS живет просто принудительно, не имея реальных альтернатив. Была надежда на WebAssembly, но видимо по политическим причинам ему перекрыли доступ в DOM API и прочим нужным API, иначе бы уже JS вылетел и из фронта. Только за счет давно доступных, к примеру, С++ dead code elimination / link time optimizations и прочих обфускаций коммерческого кода .
Например, абстракция низкоуровнего DOM API, решение проблемы композиции сложных UI элементов, инкапсуляция, унификация и т.д.
Это все не имеет никакого особого смысла и ценности для прикладной разработки. По хорошему для браузеров должны быть написаны просто хорошие библиотеки продвинутых веб компонент (или WebComponents, или и вовсе встроенных в браузер, но только не настолько непроходимо и безнадежно убогих, как input type="date"), потому как да, писать на div/input ну прям откровенно грустно. А пользоваться потом еще грустнее.
А в остальном же никакой такой прикладной логики на "продвинутом графическом терминале по имени веб-браузер" быть в принципе и не должно - он должен лишь предельно быстро отображать состояние приложения от ответов/запросов сервера, и слать на сервер когда нужно обратно значения полей ввода и прочие активности пользователя. Попытка представить браузер как некий прям полноценный архитектурный компонент программной логики приложения, с этими всеми доменными моделями, модульными уровнями абстракции, интерфейсами, сегрегацией доступа и ответственности... да ну, и это все на средстве, которое не то что нормальный компилятор/линковщик, но даже int64 тип полноценный почему-то не имеет и до сих пор в каком то странном безумии предлагает все целочисленные данные через double обрабатывать?
А так - пока HTMX большей частью живет в бэкофисе, особо много не покажешь. И он себя не позиционирует как законченный фреймворк в духе какого Oracle APEX.
По поводу зависимых полей с реактивностью - это конечно отдельно улыбнуло. Все вам покоя пример онлайн калькулятора с полями A: [ ] + B: [ ] = [ ] не дает.
HTMX такое не решает, такие примитивы на стороне фронта можно пилить на чем угодно. Он вообще больше про взаимодействия фронта и бекэнда, начиная с "а вот теперь мы элегантно выбрасываем JSON API и SPA подход от него, и SPA будем пилить теперь вот так".
Огромнейшая проблема. В сравнении с типовым подходом накидать на старте для HelloWord эдак 100 мегабайт зависимостей по типу PWABuilder. Лучшие практики, они такие.
Это и есть социокультурный феномен. Просто привыкли делать как-то так, как привыкли и как кажется проще. Один раз хорошо освоивший молоток будет вполне эффективно и шурупы забивать в доски (это кажется невероятным, пока не увидишь какого 60 летнего дедушку на стройке, который вбивает 75мм длиной каленый шуруп в доску с одного удара молотка).
В мире давным давно существует document.querySelector(), но до сих есть отдельная когорта ортодоксальных любителей $() синтаксиса, у них же есть свои доводы и мотивация. С нодой и реактом ситуация абсолютно аналогичная.
И автомобилями все не так однозначно. Да, есть 95% населения, которые и знать не знают, что у них не только тормозами на колесах, но и педалью газа управляет электронный болван (потенциально сбойный, как любая электроника и потенциально бажный, как любое ПО). И 5% которые умеют сами очень ловко дергать за ручки, крутить руль и нажимать педали, без электронного болвана в промежутке. Но те 95% они просто юзеры, им простительно. Впрочем, айтишники тоже в массе и не инженеры, и не автогонщики
HTMX невероятно гениален своей простотой, он сделал HTML/HTTP именно такими, какими они и должны были быть изначально и куда их нужно уже сейчас развивать W3C стандартами, он там прям естественно вписывается.
А в Реакте изначально есть что-то чужеродное и противоестественное. Паразитарное. И тем самым ненужное и вредное.
Реакт пытался решать проблемы тормозов манипуляции DOM в старых браузерах, пытался решать проблемы мерцания экрана при переходах по страницам. Но это все за последние годы браузеры решили и без него самостоятельно.
Потом еще что-то решал. Как правильно компоненты делать и архитектуры наслаивать, ага.
Сейчас же он из потенциально полезной новомодной технологии превратился просто в социокультурный феномен - куча народу не хочет видимо вникать в современные HTML/CSS/VanillaJS/HTTP/etc, а хочет "работать" готовыми темплейт снипетами из стековерфлоу. Но это отвалится, как только HTMX коммунити наберет нужную критическую массу готовых шаблонов, постов взаимопомощи и прочих типовых решений с книжками.
Реакт сегодня это уже технолудическая инвестиция по типу попытки в 21 веке развития паровозов и трамваев на конной тяге. Даром что ты сейчас модный спец по закидыванию хуков в топку, каток истории тебя так или иначе тебя раздавит твоей чужеродностью, ненужностью и неэффективностью в ближайшие годы (как и все остальные чумовые фреймворки).
Чтобы отобразить визуальное представление состояния сессии пользователя в браузере - Javascript же никогда не был обязателен. Просто нужно было выдать из сервера нечто в текстовом или бинарном виде виде, и С++ код браузера предельно эффективно его отрендерит и обратные интерактивности (мышеклики и поля ввода) на сервер тоже сам отошлет. Без необходимости натужного предварительно пережевывания сотен тысяч строк на стремном обфусцированном Javascript коде.
Браузер же это по сути лишь продвинутый графический терминал (по типу TTY, mstsc.exe или xfreerdp, X/Ming, etc X11). Ни у кого ведь не возникает уже чумовая идея через вкрутить Javascript в какой putty или RealVNC, а чем веб-браузер лучше?
Разумный удел Javascript в обозримой перспективе - это лишь поддерживать мелкие недоделки в HTML/CSS функционале и в интерактивно-поведенческих сценариях в браузерах (которые еще не отлили в WebKit граните). Беря поправку на то, что 95% задач (анимации, трансформации, карусели, визуальные темы и т.п.), для которых JS был просто обязателен 10 лет назад - уже сейчас и вовсе отлично решаются средствами CSS (читай - написанным на C++ движком WebKit).
И на сервере Javascript делать тоже нечего, т.к. даже автор Node.JS признал, что нода была фатальной архитектурной ошибкой и перспектив в ней никаких давно уже нет. Пока еще живет в силу инертности и социокультурного феномена, но в целом она и там тоже не родная и должна быть в итоге выпилена.
Вместе с вечно недоделанным и странно принципиальным Firefox, который перестал быть прикольным и лишь тормозит прогресс человечества (став современным IE6/11), блокируя этот самый прогресс через свою несговорчивость в части доработки стандартов.
C++ развивался и развивается эволюцией. Просто заново сделать не получится, нужна обратная совместимость.
Почему нельзя? Можно. Можно взять и на старте с плеча рубануть к примеру вот так
#define enum enum class #define var decltype(auto) #define let auto #define in : // for (var item in list) #define super __super #define self (*this) #define extends : public #define implements , public #define final static constexpr const auto
И так еще много разных вещей можно сделать без потери доступа к C библиотекам и VS Code плюшкам :)
Но многие штуки пока нельзя. К примеру красиво
#define property
сделать пока не получится. Можно только некрасиво (clang так может, gcc нет, ну и в топку его).
Да, при таком подходе можно сразу забыть про STL и Boost, но и не сильно жалко, т.к. эти штуки тоже изначально фундаментально сломаны и лучше не становятся (библиотечный код должен лежать в .a и .so файлах, а не статически inplace копироваться каждый раз по месту, раздувая результирующие бинарники до 100+ мегабайт), но это совсем отдельная и минусуемо крамольная тема.
Carbon и Cpp2,
Подобное никогда уже не взлетит только по той простой причине, что допиливать VSCode, gdb, lldb и прочие clangd для code complete там уже никто не станет, нет критической массы пользователей и финансирование тоже не выбить на это. Общий тренд - если вам эстетически не нравятся синтаксические/библиотечные костыли и подпорки в C++, то идите в Java, Kotlin, Swift или Rust и не нудите тут, не видите, люди в комитетах делом заняты.
А разве shared_ptr и unique_ptr реализованы не за счет перегрузки оператора -> ?
Позволить перегружать оператор точку нужно примерно для этого-же, а также с целью реализовать нормальный ссылочный тип с возможностью Fast-PIMPL, интерфейсы (ISomething), да много еще чего. К примеру ссылочные типы (указатели) с опциональным запретом ссылаться на NULL.
Ну и самую малость - вообще избавиться от оператора стрелки -> в коде. Во всех остальных языках (которые C/С++ подобные) оператор точка является оператором разыменования ссылочного типа, по сути указателя, и только в C++ зачем-то до сих пор нужно нужно обязательно и без вариантов всегда писать через K&R C рудиментарную форму object->call() вместо object.call()
А хотелось бы как у всех. Мелочь, но почему нет?
Тем более сами ссылки в C++ сделаны изначально криво (которые Object &obj). Они по факту ничто иное как обычные указатели с альтернативным синтаксисом, но вот уже который десяток лет все делают умный вид и утверждают что это не так, что это не совсем указатели и вообще в будущем там какой-то дополнительный новый смысл появится. А по факту лишь очередная досадная "не как у всех таковость".
В эту схему не укладывается случай, когда долгоживущие объекты 1) используются и даже создаются на fast path — in-memory database слишком медленные;
Для долгоживущих объектов можно использовать все что угодно из того великолепия, что было сочинено в индустрии. Не устраивают миллионы рандомных доступов в секунду на каких b-tree in-memory keyvalue - никто не запрещает какую lock-free hashmap с хитрым btrie взгромоздить. Или по классике shm с семафорами, и т.д. и т.п.
Я больше акцентировал том, что посмотрите/отделите короткоживущие объекты в пределах контекста внешнего вызова, им обычно не нужен классический new/delete, malloc()/free() memory management, да еще и в конкурентом виде, с подсчетами ссылок. Если их на уровне дизайна отделить от долгоживущих, то можно сразу многое упросить. В том числе получить бенефиты в NUMA средах, когда вместо хаотичного доступа к разделяемой куче основная работа будет идти в worker's binded obstacks/memory regions, которые часто даже за пределы локального кеша L3 не убегут, не успеют, там и будут в итоге "обнулены/очищены".
Даже вот эта самая задача парсинга, что в топике озвучивалась. Имеем на входе некий короткоживущий request payload с каким JSON или XML. Прогоняем его stringcopy-free, lock-free парсером, получаем некий массив из структур (или просто вызовов) вида int type, int offset, int size, никакие строки из этого JSON или XML пока отдельно копировать и аллоцировать деревьями не надо, боже упаси.
И уже затем отправляем куда-то в разделяемое хранилище вызовы со string_view параметрами (pointer+size), ссылающимися на исходный request payload blob, и пусть вот это хранилище само куда там ему надо себе потом накопирует нужных строк-данных из исходного JSON blob-а в свои какие конкурентно-доступные структуры.
А в конце вызова этот короткоживущий request payload вместе с массивом от парсера (которые оба изначально сидят в obstack) берем и удаляем переводом HWM в ноль. Никакие счетчики ссылок при этом не нужны, как и примитивы многопоточной синхронизации, зачем там что-то усложнять?
Modern C++ фундаментально сломан просто способом реализации RAII.
move semantics, perfect forwarding, auto &&, prvalue, xvalue, glvalue и прочие костыли с подпорками. Это все не сильно приятно читать, оно выглядит слишком уродливо, слишком "не так, как у всех".
Привыкнуть можно, но можно было бы и нормально еще раз заново сделать. Там то все что и нужно было, так это позволить оператор "." перекрыть, но эту возможность видимо из принципа запретили, никаких других объяснений нет (аргументы против у Страустрапа в соотвествуем PR выглядят весьма и весьма неубедительно).
это может быть множество асинхронных операций, которые шарят какие-то данные между собой.
Если это два внешних асинхронных вызова одного сервиса (chat-service?) - то там все просто, in-/cross- process message passing, shared in-memory database и т.п. И никаких direct memory references. Между двумя внешними вызовами разница в бесконечность (0.1..5 секунд), а obstack может жить лишь миллисекунды by contract.
А вот если этот один условный external service method call предусматривает раздерг уже внутри интрасети еще кучи своих асинхронных вызовов (один микросервис вызывает другие микросервисы), то там да, там все немного веселее, если брать в расчет ограничение на время жизни обработчика в миллисекунды.
В общем случае (надеюсь я тут не сильно много крамолы пишу) обработчик внешнего события должен инициировать все ему нужные асинхронные вызовы внутренних микросервисов, затем сохранить куда-то в in-memory database свой контекст (session id, cookies, URI, variables, socket fd, etc) и ... завершить выполнение/освободить obstack. Передав менеджеру запросов свой подсохраненный локально контекст с напутствием - "ну там когда вот все те микросервисы свой payload отдадут, через сколько там миллисекунд, ты вызови меня снова с вот этим session_id, я и займусь (до)обработкой того, что они мне там понаприсылали".
Ну а менеджер запросов (который epool based) должен уже обеспечить все эти внутренние вызовы, HTTP(s) request/response и прочее, у него внутри логик особо и нет, кроме вот этих кому куда чего слать и кого потом заново вызывать для продолжения обработки, ломаться на dangling pointer там нечему.
Кстати да, вот тут на внутренних микросервисах появляется уже третий класс памяти - session based obstacks (в дополнение к service method call obstacks и к long-living in-memory database). Которыми рулит Session manager: если очень грубо - под каждый socket fd заводится свой session level obstack region, куда сначала из сокета пишется request, потом response, ну и после отправки response можно снова session level obstack memory free/reuse делать/следующий keepalive request обрабатывать. Вот тут извиняюсь, не хотелось сразу все секреты выдавать :)
Ну а если внутренние вызовы не асинхронные, но долгоиграющие (классика - вызов SQL базы данных)... что мешает их сделать асихронными через внешний или внутренний брокер сообщений с пуллингом, ну или просто сразу синхронно подождать, пока там SQL база не вернет свое, беря в расчет то, что ограничения ее внутреннего throughput никакой асинхронностью не преодолеть (ну не может никакая SQL база в одновременные 10к SELECT, даже в 100 уже не может).
С другой стороны, в своей работе я редко вижу когда софт упирается в скорость процессора. Чаще - как раз в объем свободной памяти.
Замечание справедливое. Но нужно правильно понимать, что в современном мире есть условно 64 бита, где про ограничения памяти можно уже вообще не думать.
И все что менее 64 бит - это как правило контроллеры и прочая подобная микроэлектроника, где MISRA вообще предписывает использование исключительно предалоцированных при старте областей памяти и стека. И никаких динамических куч.
Потому утверждение, что obstack не применимы ибо "а вдруг память" закончится - оно сугубо академическое. В конце концов это все можно довольно просто замерить (перекрыв/протрасировав new / malloc() вызовы). Обычно в 99% случаев там даже до пару мегабайт краткосрочных объектов на внешний вызов не доходит, а 95% случаев - даже до 640кбайт, если говорить про какой веб сервис :)
Проблема в том, что у С/С++ самая лучшая инструментальная инфраструктура (бэкэнд, оптимизирующий компилятор, LTO, DCD, LLVM и вот это вот все). Все остальные находятся на уровне если не детсада, то строительного техникума и курят в сторонке. Альтернативы ей нет и не предвидится.
Но фронтэнд, который для человеков, он не просто эстетически ужасен, он какой-то просто человеконенавистнечиский. Простые вещи делаются до предела странными, сложными и многословными конструкциями, это никак не способствует чтению и верификации кода. И делается почти всегда не как у всех, что особенно печально.
Про то, что изначально все базовые примитивы принципиально сделаны не так как у Swift, Kotlin, Java и пр. наследников С++ это понятно (типа кто там первый был и мог подумать как на самом деле надо было), но что мешало уже сделать потом нормально? Зачем тянуть в века это замшелое и посредственное говно мамонта под названием библиотека SGI STL, зачем-то называя ее стандартом? Она даже хешмапы делает плохо, есть более быстрые и удобные. И почему именно эту библиотеку в стандарты двинули, почему нельзя взять любую другую, которая хотя бы строки и контейнеры будет делать в стиле Java (к примеру), и в camelStyle нотации имен? Сколько можно этими подчеркиваниями мучаться?
100500 способов 32 битное целое называть - это вообще зачем? Почему нельзя один раз всем сказать, что со следующего стандарта int это всегда знаковое 32 битное целое и успокойтесь там уже со своим PDP-11, сидите в своем музее на на старом стандарте, вас никто не трогает.
И кому реально так сильно впилась эта обратная совместимость, все равно же без флагов --std= в реальной жизни не обойтись? Хочется писать в духе С++98, ну и отлично - вот вам песочница и отдельные .deb/.rpm со "стандартными" библиотеками, не плачьте.
А вот небезопасные штуки доступа к памяти можно было вполне запретить по дефолту, в равной степени как и принудительную верификацию диапазонов и прочих выходов за границ обязать делать - это все вполне можно было через опцию флажками компилятора привинтить, да и стандартную библиотеку давно пора переписать с нуля, начиная с спецификаций интерфейсов, тут никакой Америки нет. Кому прям очень надо там для какого CRC32 алгоритма - старый стандарт или unsafe флаги в помощь.
Но мир видимо решил проявить упорство в своем безумии и все надежды возложить на весьма странных парней из Rust (как минимум странных своими чумовыми названиями - все эти трейты, крейты, опять не похожий на всех синтаксис), дескать они уж точно знают как надо. Наивность веры в Rust просто невероятно поражает, учитывая, что им пока не удалось ничего более внятного, чем несколько относительно неплохих библиотек для веб микросервисов написать и сильно ограниченно их популяризовать (и то, даже на C++ есть библиотеки и побыстрее, и в целом покруче).
Альтернатива где? Не на Swift же переходить? Хотя поневоле задумаешься, они там уже и на UTF-8 догадались переползти, и даже начали макросы применять, не пройдет и 30 лет как совсем взрослыми станут.
По теме совсем нечего сказать? Это печально (с).
Кстати, а упомянутые "фреймы" это вообще что? Это так по-молодежному frameworks уже стало принято называть? Типа как "собес" это оказывается собеседование, а вовсе не то место, где СНИЛСы выдают?
Ок, тебя попросили привести пример действительно сложных интерфейсов. В результате мы услышали про клики на свечах на SVG графиках, и увидели невнятную попытку самоутверждения демонстрацией чувства превосходства в финале.
Это вообще не спортивно. А можно было и про хитрые LOV с диалогами поиска, и про настраиваемые/сохраняемые фильтры в каких pivot или обычных гридах поговорить, для начала. И про offline mode в PWA, чтоб уж точно HTMX на лопатки положить.
Впрочем это наверное уже middle уровень, джуниорам такое не поручают? Ну и ладно, как нибудь в другой раз.
SSE/Websockets лично я не занимался, да, чятики пилил другой человек. Ну в чем там сложность-то? sectet's hash можно послать каким угодно способом, да хоть как часть пользовательских данных. В чем откровение-то?
Клики на свечу? Да, такое я тоже не делал. Дальше что?
Загуглить "Add onclick event to SVG element" и найти готовый снипет может ребенок лет семи наверное. И потом еще штук 30 снипетов на выбор, какой больше глазу приятнее будет.
Тоже мне ловля на живца, смешно. Это все задачи уровня pre-junior. Решаются правым мизинцем и половинкой гипоталамуса (и ChatGPT вполне справится), там больших ресурсов и не требуется.
Зачем? auth_token куки шлет браузер. Можно и без кукисов, в HTMX есть возможность дописывать произвольные request headers, но зачем усложнять?
Про невалидную куку не совсем понятно. Как обрабатывать на HTMX ошибки от сервера? Да как угодно, можно заново редиректить на страницу авторизации (сервер инициирует редирект клиента), или на стороне браузера можно перехватывать какие 403/404. Можно и так и так, как угодно. Там вообще нет никаких ограничений и навязываемых подходов, только новые дополнительные к HTML5/CSS3/JS6 фичи, которые можно использовать, можно не использовать (правда автор странно любит и поддерживает даже и IE11, но шутки по этому поводу оставим, у него видимо это личное).
В смысле умеет? HTMX штатно сам умеет по клику или какому еще событию получить от сервера HTML код, встроить его куда сервер скажет, при случае вызвать указанный сервером JS или и вовсе сделать какой redirect/page reload. А что сверху - всегда можно ловко донавернуть самому в нужных местах разными способами, плюс расширения всякие готовые.
Там нет ничего военного - всякими разными подходами можно отработать действия пользователя и выслать на сервер request, куда записать тоже что угодно, и получить от сервера ответ - по дефолту один кусок HTML и target element id (но можно и много кусков, и много target), скрипты потом обработчиками вызывать, события получать/заново слать, и т.д. и т.п. Там нет ограничений, в отличие от. Полная свобода. Там только одно ограничение - нет обязательности в React/Vue/Angular и любого иного натужного OpinionWare в зависимостях.
Только htmx.min.js и браузер с его базовым функционалом, этого уже достаточно для полноценного SPA. А дальше можно самому развивать и декорировать куда захочется.
Элементарно. Один из способов - регистрируются custom events, на них вешаются обработчики. Сервер шлет этот самый event, обработчики делают что им там нужно, получив нужные данные через event параметры. И это лишь один из способов.
Может стоит документацию почитать и примеры поизучать? Они там очень прикольные, читаются легко, задорно и весело, в отличие от React/Vue/Angular тягомотины. Первая глава и эссе особенно заставляют прям задуматься о безумии этого вашего корпоративного софтостроения и не только.
Вообще не правильно. В самом начале сервер просто "рендерит" HTML на создание веб компонента для рисования графика. Благо их уже сотни готовых на любой вкус и цвет (в т.ч. и для чисто vanilla js).
Генерит или на первоначальной загрузке страницы или в момент когда пользователь кликнет на какую кнопку или закладку с "Динамика цен". Результатом обработки нажатия кнопки будет прилетевший в нужный element id этот самый HTML фрагмент с этим графиком и каким приложенным javascript кодом c данными. Lazy loading в действии. По сути гидратация через SSR, или как там в реато-SPA это сейчас называется.
И дальше как обычно - туда сюда шлем на/с сервера хоть JSONы, хоть сразу новые SVG элементы для графиков, хоть '<script></script>' на выполнение это кому как будет веселее.
HTMX это же не про "э блин, а вот теперь все снова все делаем типа только на HTML5/CSS3/NoJavascript, ну ок и вот чутка AJAX но больше нини", вовсе нет.
HTMX - это про "а вот сейчас мы элегантным, но мощным пинком выбрасываем наследие React/Vue/Angular//Svelte/Belte/Next/Nuxt/Naxt/Nixt/Nyxt../../../../../ (N=100500)xt" и начинаем жить нормальной жизнью фуллстек девелопера с уклоном в какие бухгалтерии, без выгорания на хуках и history API.
Ну и? В чем проблема?
На HTMX нельзя сделать график со свечами или ордербук через SSE/WebSockets/etc в реалтайме?
Конкретнее, конкретнее пожалуйста. Я ведь тоже могу типа сильно умным прикинуться и рассказать, что на HTMX прям никак нельзя BOM процессы для сметно-кадастрового геодезического центра со спутниковым мониторингом перемещения грузовиков в реальном времени запилить, только на реакте, только на нем любимом.
Или какое CAE твердотельное моделирование механики жидких сред для спутникового коллайдера.
Казалось бы, при чем тут, да?
Так будет конкретика?
Причем тут примитивизм todo examples? HTMX это просто подход, это не законченный фреймворк-инфраструктура с темплейтами аля Wordpress или Joomla.
Это по сути просто библиотека (да, ок, для PJAX и еще кое чего).
Если сравнивать с автомобилем - это да, по сути старый двигатель, но уже нового принципа действия, не ДВС, не электродвигатели, а скорее гравицапа. Которую можно вкрутить в свой старый Долориан и получить сосем новое некое качество перемещения из точки А в точку Б.
А дописать (переосмыслить, написать заново) нужные UI компоненты и в целом шаблоны - это вполне достижимая, веселая и задорная задача на ближайшие пару месяцев, как раз теперь и повод есть.
Ну или продолжать натужно ездить на индийском Реакт/Нода автобусе, не зря же права категории D последние пять лет дружно всем отделом получали :)
Что такое сложный проект со сложными интерфейсами? Рассказывать про over 9000 примитивных CRUD страниц не надо - из даже если и будет более 100500, то суть их примитивности (качество) от количества оных не изменится.
Тогда что такое тогда сложный интерфейс? Какой необанк по типу Тинькофф это сложный или не сложный? Озон, алиэкспресс?
Что именно там такого в этих "сложных" интерфейсах, что в принципе нельзя сделать через HTMX с небольшими вкраплениями VanillaJS и WebComponents?
Можно пример? Типа вот берем форму заказа от Али, и... ? Наверное оплату через QR код по СПБ не прикрутить, или OAuth какой, да?
Конкретика будет? Или как всегда ограничимся абстрактными пугалками вида "а вот как только у вас проект станет достаточно сложный, так сразу начнутся проблемы идемпотентности зависимостей в силу роста величины модульного зацепления" ?
Звон, трезвон, альтернативы, зачем это все? Есть же "тренд", что на Javascript будет переписано тотально вот вообще все, от фронта, бека и чуть-ли не JаvascriptOS вот вот уже будет с нами. Ну и? Когда же уже будет всеобщий JS Universe?
На самом же деле это все просто от инертности мышления. В браузерах весьма изначально странный по своей природе JS живет просто принудительно, не имея реальных альтернатив. Была надежда на WebAssembly, но видимо по политическим причинам ему перекрыли доступ в DOM API и прочим нужным API, иначе бы уже JS вылетел и из фронта. Только за счет давно доступных, к примеру, С++ dead code elimination / link time optimizations и прочих обфускаций коммерческого кода .
Это все не имеет никакого особого смысла и ценности для прикладной разработки. По хорошему для браузеров должны быть написаны просто хорошие библиотеки продвинутых веб компонент (или WebComponents, или и вовсе встроенных в браузер, но только не настолько непроходимо и безнадежно убогих, как input type="date"), потому как да, писать на div/input ну прям откровенно грустно. А пользоваться потом еще грустнее.
А в остальном же никакой такой прикладной логики на "продвинутом графическом терминале по имени веб-браузер" быть в принципе и не должно - он должен лишь предельно быстро отображать состояние приложения от ответов/запросов сервера, и слать на сервер когда нужно обратно значения полей ввода и прочие активности пользователя. Попытка представить браузер как некий прям полноценный архитектурный компонент программной логики приложения, с этими всеми доменными моделями, модульными уровнями абстракции, интерфейсами, сегрегацией доступа и ответственности... да ну, и это все на средстве, которое не то что нормальный компилятор/линковщик, но даже int64 тип полноценный почему-то не имеет и до сих пор в каком то странном безумии предлагает все целочисленные данные через double обрабатывать?
На офсайте есть ссылка на, https://github.com/rajasegar/awesome-htmx для начала.
А так - пока HTMX большей частью живет в бэкофисе, особо много не покажешь. И он себя не позиционирует как законченный фреймворк в духе какого Oracle APEX.
По поводу зависимых полей с реактивностью - это конечно отдельно улыбнуло. Все вам покоя пример онлайн калькулятора с полями A: [ ] + B: [ ] = [ ] не дает.
HTMX такое не решает, такие примитивы на стороне фронта можно пилить на чем угодно. Он вообще больше про взаимодействия фронта и бекэнда, начиная с "а вот теперь мы элегантно выбрасываем JSON API и SPA подход от него, и SPA будем пилить теперь вот так".
Огромнейшая проблема. В сравнении с типовым подходом накидать на старте для HelloWord эдак 100 мегабайт зависимостей по типу PWABuilder. Лучшие практики, они такие.
Это и есть социокультурный феномен. Просто привыкли делать как-то так, как привыкли и как кажется проще. Один раз хорошо освоивший молоток будет вполне эффективно и шурупы забивать в доски (это кажется невероятным, пока не увидишь какого 60 летнего дедушку на стройке, который вбивает 75мм длиной каленый шуруп в доску с одного удара молотка).
В мире давным давно существует document.querySelector(), но до сих есть отдельная когорта ортодоксальных любителей $() синтаксиса, у них же есть свои доводы и мотивация. С нодой и реактом ситуация абсолютно аналогичная.
И автомобилями все не так однозначно. Да, есть 95% населения, которые и знать не знают, что у них не только тормозами на колесах, но и педалью газа управляет электронный болван (потенциально сбойный, как любая электроника и потенциально бажный, как любое ПО). И 5% которые умеют сами очень ловко дергать за ручки, крутить руль и нажимать педали, без электронного болвана в промежутке. Но те 95% они просто юзеры, им простительно. Впрочем, айтишники тоже в массе и не инженеры, и не автогонщики
HTMX невероятно гениален своей простотой, он сделал HTML/HTTP именно такими, какими они и должны были быть изначально и куда их нужно уже сейчас развивать W3C стандартами, он там прям естественно вписывается.
А в Реакте изначально есть что-то чужеродное и противоестественное. Паразитарное. И тем самым ненужное и вредное.
Реакт пытался решать проблемы тормозов манипуляции DOM в старых браузерах, пытался решать проблемы мерцания экрана при переходах по страницам. Но это все за последние годы браузеры решили и без него самостоятельно.
Потом еще что-то решал. Как правильно компоненты делать и архитектуры наслаивать, ага.
Сейчас же он из потенциально полезной новомодной технологии превратился просто в социокультурный феномен - куча народу не хочет видимо вникать в современные HTML/CSS/VanillaJS/HTTP/etc, а хочет "работать" готовыми темплейт снипетами из стековерфлоу. Но это отвалится, как только HTMX коммунити наберет нужную критическую массу готовых шаблонов, постов взаимопомощи и прочих типовых решений с книжками.
Реакт сегодня это уже технолудическая инвестиция по типу попытки в 21 веке развития паровозов и трамваев на конной тяге. Даром что ты сейчас модный спец по закидыванию хуков в топку, каток истории тебя так или иначе тебя раздавит твоей чужеродностью, ненужностью и неэффективностью в ближайшие годы (как и все остальные чумовые фреймворки).
Чтобы отобразить визуальное представление состояния сессии пользователя в браузере - Javascript же никогда не был обязателен. Просто нужно было выдать из сервера нечто в текстовом или бинарном виде виде, и С++ код браузера предельно эффективно его отрендерит и обратные интерактивности (мышеклики и поля ввода) на сервер тоже сам отошлет. Без необходимости натужного предварительно пережевывания сотен тысяч строк на стремном обфусцированном Javascript коде.
Браузер же это по сути лишь продвинутый графический терминал (по типу TTY, mstsc.exe или xfreerdp, X/Ming, etc X11). Ни у кого ведь не возникает уже чумовая идея через вкрутить Javascript в какой putty или RealVNC, а чем веб-браузер лучше?
Разумный удел Javascript в обозримой перспективе - это лишь поддерживать мелкие недоделки в HTML/CSS функционале и в интерактивно-поведенческих сценариях в браузерах (которые еще не отлили в WebKit граните). Беря поправку на то, что 95% задач (анимации, трансформации, карусели, визуальные темы и т.п.), для которых JS был просто обязателен 10 лет назад - уже сейчас и вовсе отлично решаются средствами CSS (читай - написанным на C++ движком WebKit).
И на сервере Javascript делать тоже нечего, т.к. даже автор Node.JS признал, что нода была фатальной архитектурной ошибкой и перспектив в ней никаких давно уже нет. Пока еще живет в силу инертности и социокультурного феномена, но в целом она и там тоже не родная и должна быть в итоге выпилена.
Вместе с вечно недоделанным и странно принципиальным Firefox, который перестал быть прикольным и лишь тормозит прогресс человечества (став современным IE6/11), блокируя этот самый прогресс через свою несговорчивость в части доработки стандартов.
Почему нельзя? Можно. Можно взять и на старте с плеча рубануть к примеру вот так
#define enum enum class
#define var decltype(auto)
#define let auto
#define in : // for (var item in list)
#define super __super
#define self (*this)
#define extends : public
#define implements , public
#define final static constexpr const auto
И так еще много разных вещей можно сделать без потери доступа к C библиотекам и VS Code плюшкам :)
Но многие штуки пока нельзя. К примеру красиво
#define propertyсделать пока не получится. Можно только некрасиво (clang так может, gcc нет, ну и в топку его).
#define property(...) ____VA_CHOOSE(____PROPERTY, VA_ARGS)#define ____PROPERTY_1(getter) __declspec(property(get=getter))
#define ____PROPERTY_2(getter, setter) __declspec(property(get=getter, put=setter))
Да, при таком подходе можно сразу забыть про STL и Boost, но и не сильно жалко, т.к. эти штуки тоже изначально фундаментально сломаны и лучше не становятся (библиотечный код должен лежать в .a и .so файлах, а не статически inplace копироваться каждый раз по месту, раздувая результирующие бинарники до 100+ мегабайт), но это совсем отдельная и минусуемо крамольная тема.
Подобное никогда уже не взлетит только по той простой причине, что допиливать VSCode, gdb, lldb и прочие clangd для code complete там уже никто не станет, нет критической массы пользователей и финансирование тоже не выбить на это. Общий тренд - если вам эстетически не нравятся синтаксические/библиотечные костыли и подпорки в C++, то идите в Java, Kotlin, Swift или Rust и не нудите тут, не видите, люди в комитетах делом заняты.
А разве shared_ptr и unique_ptr реализованы не за счет перегрузки оператора -> ?
Позволить перегружать оператор точку нужно примерно для этого-же, а также с целью реализовать нормальный ссылочный тип с возможностью Fast-PIMPL, интерфейсы (ISomething), да много еще чего. К примеру ссылочные типы (указатели) с опциональным запретом ссылаться на NULL.
Ну и самую малость - вообще избавиться от оператора стрелки -> в коде. Во всех остальных языках (которые C/С++ подобные) оператор точка является оператором разыменования ссылочного типа, по сути указателя, и только в C++ зачем-то до сих пор нужно нужно обязательно и без вариантов всегда писать через K&R C рудиментарную форму object->call() вместо object.call()
А хотелось бы как у всех. Мелочь, но почему нет?
Тем более сами ссылки в C++ сделаны изначально криво (которые Object &obj). Они по факту ничто иное как обычные указатели с альтернативным синтаксисом, но вот уже который десяток лет все делают умный вид и утверждают что это не так, что это не совсем указатели и вообще в будущем там какой-то дополнительный новый смысл появится. А по факту лишь очередная досадная "не как у всех таковость".
Для долгоживущих объектов можно использовать все что угодно из того великолепия, что было сочинено в индустрии. Не устраивают миллионы рандомных доступов в секунду на каких b-tree in-memory keyvalue - никто не запрещает какую lock-free hashmap с хитрым btrie взгромоздить. Или по классике shm с семафорами, и т.д. и т.п.
Я больше акцентировал том, что посмотрите/отделите короткоживущие объекты в пределах контекста внешнего вызова, им обычно не нужен классический new/delete, malloc()/free() memory management, да еще и в конкурентом виде, с подсчетами ссылок. Если их на уровне дизайна отделить от долгоживущих, то можно сразу многое упросить. В том числе получить бенефиты в NUMA средах, когда вместо хаотичного доступа к разделяемой куче основная работа будет идти в worker's binded obstacks/memory regions, которые часто даже за пределы локального кеша L3 не убегут, не успеют, там и будут в итоге "обнулены/очищены".
Даже вот эта самая задача парсинга, что в топике озвучивалась. Имеем на входе некий короткоживущий request payload с каким JSON или XML. Прогоняем его stringcopy-free, lock-free парсером, получаем некий массив из структур (или просто вызовов) вида int type, int offset, int size, никакие строки из этого JSON или XML пока отдельно копировать и аллоцировать деревьями не надо, боже упаси.
И уже затем отправляем куда-то в разделяемое хранилище вызовы со string_view параметрами (pointer+size), ссылающимися на исходный request payload blob, и пусть вот это хранилище само куда там ему надо себе потом накопирует нужных строк-данных из исходного JSON blob-а в свои какие конкурентно-доступные структуры.
А в конце вызова этот короткоживущий request payload вместе с массивом от парсера (которые оба изначально сидят в obstack) берем и удаляем переводом HWM в ноль. Никакие счетчики ссылок при этом не нужны, как и примитивы многопоточной синхронизации, зачем там что-то усложнять?
Modern C++ фундаментально сломан просто способом реализации RAII.
move semantics, perfect forwarding, auto &&, prvalue, xvalue, glvalue и прочие костыли с подпорками. Это все не сильно приятно читать, оно выглядит слишком уродливо, слишком "не так, как у всех".
Привыкнуть можно, но можно было бы и нормально еще раз заново сделать. Там то все что и нужно было, так это позволить оператор "." перекрыть, но эту возможность видимо из принципа запретили, никаких других объяснений нет (аргументы против у Страустрапа в соотвествуем PR выглядят весьма и весьма неубедительно).
Если это два внешних асинхронных вызова одного сервиса (chat-service?) - то там все просто, in-/cross- process message passing, shared in-memory database и т.п. И никаких direct memory references. Между двумя внешними вызовами разница в бесконечность (0.1..5 секунд), а obstack может жить лишь миллисекунды by contract.
А вот если этот один условный external service method call предусматривает раздерг уже внутри интрасети еще кучи своих асинхронных вызовов (один микросервис вызывает другие микросервисы), то там да, там все немного веселее, если брать в расчет ограничение на время жизни обработчика в миллисекунды.
В общем случае (надеюсь я тут не сильно много крамолы пишу) обработчик внешнего события должен инициировать все ему нужные асинхронные вызовы внутренних микросервисов, затем сохранить куда-то в in-memory database свой контекст (session id, cookies, URI, variables, socket fd, etc) и ... завершить выполнение/освободить obstack. Передав менеджеру запросов свой подсохраненный локально контекст с напутствием - "ну там когда вот все те микросервисы свой payload отдадут, через сколько там миллисекунд, ты вызови меня снова с вот этим session_id, я и займусь (до)обработкой того, что они мне там понаприсылали".
Ну а менеджер запросов (который epool based) должен уже обеспечить все эти внутренние вызовы, HTTP(s) request/response и прочее, у него внутри логик особо и нет, кроме вот этих кому куда чего слать и кого потом заново вызывать для продолжения обработки, ломаться на dangling pointer там нечему.
Кстати да, вот тут на внутренних микросервисах появляется уже третий класс памяти - session based obstacks (в дополнение к service method call obstacks и к long-living in-memory database). Которыми рулит Session manager: если очень грубо - под каждый socket fd заводится свой session level obstack region, куда сначала из сокета пишется request, потом response, ну и после отправки response можно снова session level obstack memory free/reuse делать/следующий keepalive request обрабатывать. Вот тут извиняюсь, не хотелось сразу все секреты выдавать :)
Ну а если внутренние вызовы не асинхронные, но долгоиграющие (классика - вызов SQL базы данных)... что мешает их сделать асихронными через внешний или внутренний брокер сообщений с пуллингом, ну или просто сразу синхронно подождать, пока там SQL база не вернет свое, беря в расчет то, что ограничения ее внутреннего throughput никакой асинхронностью не преодолеть (ну не может никакая SQL база в одновременные 10к SELECT, даже в 100 уже не может).
Замечание справедливое. Но нужно правильно понимать, что в современном мире есть условно 64 бита, где про ограничения памяти можно уже вообще не думать.
И все что менее 64 бит - это как правило контроллеры и прочая подобная микроэлектроника, где MISRA вообще предписывает использование исключительно предалоцированных при старте областей памяти и стека. И никаких динамических куч.
Потому утверждение, что obstack не применимы ибо "а вдруг память" закончится - оно сугубо академическое. В конце концов это все можно довольно просто замерить (перекрыв/протрасировав new / malloc() вызовы). Обычно в 99% случаев там даже до пару мегабайт краткосрочных объектов на внешний вызов не доходит, а 95% случаев - даже до 640кбайт, если говорить про какой веб сервис :)