Приветствую коллеги. Имеется react ts проект, внутрь main поля на

сайте в браузере должен загрузится и запустится unity engine с 2Д проектом - в которую будут отправлены данные из react проекта с координатами узлов графа и связи узлов графа между собой.
Вопрос: насколько верно и логично использовать web gl если речь может идти о high load инфраструктуре ? Что меня ждет при реализации ?

Реакт, веб, хайлоад... Звучит как что то сомнительное и странное. Либо вы преувеличиваете в обьемах данных и скорости потока, либо к отображения этих данных хайлоад не имеет значения и его можно не упоминать. Не понятно что за сомнения?

По тому что может ждать: При настоящей высокой загрузке надо учитывать, что одна машина не будет справляться с потоками, которые генерируют десятки машин. Предлагаю сразу мыслить так, что данные будут поступать с 5-10 машин на вашу ноду. Я обычно объясняю это водой. Представьте колодец с водой. Колодец - это брокер, или несколько брокеров в вашей системе, конкретная реализация не важна, будь то kafka, mq/mqtt ил что либо ещё, поток от других систем - это вода, она заливается в колодец, или в несколько колодцев. Важно понимать, что колодцы не безграничны, из систем заливаются моря и океаны, скорость залития зависит от числа труб ( это наши продюсеры, паблишеры, приложения которые формируют сообщения и данные) подключённых к колодцу по которым вода заливается в них. Чтобы колодец не переполнился (в нашем случае это потеря данных или вообще отказ кластера) нужно выкачивать воду вовремя, колодец должен в меру опорожняться в ваши конечные системы (тут будут наши ноды, нода представляет собой один экземпляр подписчика или потребителя, задача экземпляра получить порцию данных или сообщений и обработать, подготовить для визуализации), если выкачивать его слишком быстро - он будет сухой, а значит инфраструктура обрабатывающая поток данных будет простаивать, а значит избыточна (а это огромные деньги). Если колодец будет постоянно переполняться - это ещё хуже, система просто не справляется (захлёбывание приводит к потере данных, для многих это критично, кроме потери данных можно положить всю инфраструктуру, зависит всё от настроек брокеров/колодцев). Ну, а дальше, в идеале, после обработки вашими нодами - у вас есть вода, расфасованая в бутылки или стаканы, вы можете использовать её для того чтобы визуализировать, например, в юнити. Из всего этого следует, что нужно стараться работать с порциями данных, воду нужно разливать в стаканы, а из стакана пить по глотку. Проектируя такие системы - это надо держать в голове. Если всё что я описал кажется избыточным - у вас нет высокой нагрузки, не думайте о ней, возможно у вас есть узкие горлышки или места где требуется что то оптимизировать, но нет плотного потока данных 24/7.

Да вроде ничего, веб сборка юньки крутится на клиенте и вообще никак не трогает сервер если ты конешн на него запросы не кидаешь

Нет то что вы написали уместно и будет развёрнуто в к8s. Что касается highload-da в визуализации, то речь идёт о графе с количеством узлов около 10-20 тыс. Может доходить и до 50* тыс. в худших случаях. Первая мысль это partially rendering. Я не пытался но что если существует способ частично подгружать (генерировать)граф, тобишь подгружать там где камера user-a на карте. Т.е. своего рода генераци карты как в Майнкрафте Это возможно?

Сходу скажу что все опытные разработчики предупреждают что юнити очень плохой инструмент для работы с генерацией объектов в режиме реального времени. В ней генерация будет замораживать основной поток на время инстанцирования. Более того, будут проблемы с производительностью. Это не мой личный опыт, в юнити я джун-любитель, а опыт хороших спецов. Опять же, всё зависит от подхода к генерации. По узлам - есть острая необходимость отображать человеку все 50к узлов? Вы же понимаете что человек даже 1000 из них не сможет проанализировать? В таких вещах применяются приёмы упрощения, если нужно показать как тут всё круто в системе что аж 50к элементов есть - можно обманывать пользователя, рисовать приближения, никто на глаз этого не заметит. При масштабировании и детализации - можно увеличивать точность данных. Это помогает визуализировать что угодно в любых объёмах. Так же, нужно показывать только важные и нужные данные, а менее важные при минимальном масштабе вообще выкидывать. Про готовые решения графов в юнити - у юнити нет такого. А если есть - это сторонние решения. Так что нужно искать того кто с ними сталкивался, либо читать документацию таких проектов, либо опрашивать разработчиков этих инструментов.

Ну а в целом, лично я не вижу проблем именно в вебе. При грамотном подходе можно на WebGL сделать очень производительное приложение.

Надеюсь в ходе реализации смогу локализовать проблемы и задавать более targeting вопросы. Спасибо за подробную информацию 👍🏻