M>а какие аргументы в пользу блэйзор? не нужно отдельного фронтендера или блэйзор в чем-то лучше реакта?

1. Унифицированный coding experience идентичный обычной разработке на .net. Не нужен отдельный редактор (VsCode, WebStorm), не нужно заморачиваться со сборкой (npm/webpack/rollup), не нужен выделенный фронтендер (если, конечно, нет упора на pixel perfect-верстку и всякие css/js эффекты), достаточно будет фулстека с минимальными навыками верстки.
2. Это WebAssembly. Бинарный код, по сути. Небольшой по размеру и очень быстрый.
3. Достаточно стабильный фреймворк, в отличие от реакта, где каждые пол-года что-нибудь да меняется.

M>github actions они только в десктопной версии?
Они только в облачной версии. В том смысле, что GitHub — он сам по себе облачный. Его нельзя развернуть standalone. По крайней мере, я о таком варианте не слышал.

M>а еще вопрос вот такой.
M>решили попробовать микросервисную архитектуру впервые. это нынче еще в тренде?
До кучи возьмите акторный фреймворк, in-memory grid и пишите на F#. Можно ещё AI/Chat GPT прикрутить. Это тоже сейчас модно.
Это я к тому, что строить архитектуру по принципу "в тренде/не в тренде", это путь боли и отчаяния.

M>и если в тренде то вопрос такой. чтобы сократить время на изучение настроек кубера, можно же вначале написать микросервисный апп и запустить это не в контейнерах в иис?
Можно, но бесшовно его потом не перенесешь. Все равно придется заморочиться и с настройками кубера, и со сборкой образов, и с выпиливанием iis-специфичного функционала.

M>а какие аргументы в пользу блэйзор? не нужно отдельного фронтендера или блэйзор в чем-то лучше реакта?

1. Унифицированный coding experience идентичный обычной разработке на .net. Не нужен отдельный редактор (VsCode, WebStorm), не нужно заморачиваться со сборкой (npm/webpack/rollup), не нужен выделенный фронтендер (если, конечно, нет упора на pixel perfect-верстку и всякие css/js эффекты), достаточно будет фулстека с минимальными навыками верстки.
2. Это WebAssembly. Бинарный код, по сути. Небольшой по размеру и очень быстрый.
3. Достаточно стабильный фреймворк, в отличие от реакта, где каждые пол-года что-нибудь да меняется.

M>github actions они только в десктопной версии?
Десктопная версия — это GitHub Desktop что ли? Это просто UI-клиент для гита. А тебе нужна серверная часть, которая у них в облаке крутится.
Т.о. GitHub actions есть только в облачной версии. В том смысле, что GitHub — он сам по себе облачный. Его нельзя развернуть self-hosted. По крайней мере, я о таком варианте не слышал.
Есть Gitea, который заявляет поддержку GitHub actions, но насколько он рабочий, не скажу, не пользовался.

M>а еще вопрос вот такой.
M>решили попробовать микросервисную архитектуру впервые. это нынче еще в тренде?
До кучи возьмите акторный фреймворк, in-memory grid и пишите на F#. Можно ещё AI/Chat GPT прикрутить. Это тоже сейчас модно.
Это я к тому, что строить архитектуру по принципу "в тренде/не в тренде", это путь боли и отчаяния.

M>и если в тренде то вопрос такой. чтобы сократить время на изучение настроек кубера, можно же вначале написать микросервисный апп и запустить это не в контейнерах в иис?
Можно, но бесшовно его потом не перенесешь. Все равно придется заморочиться и с настройками кубера, и со сборкой образов, и с выпиливанием iis-специфичного функционала.