Я бы так не сказал. Во первых, можно сделать по AppHost'у на каджый сервис в репе - можно будет хотя бы для 1 сервиса, получать плюхи аспайра, например для поднятия инфраструктуры
Но еще, есть возможность сделать монорепу на гит сабмодулях - и там уже сделать верхнеуровневый солюшн, в который можно запихать нужный сет проектов, для их запуска
Да ладно вам, это всего лишь шутка была, не воспринимайте это всерьёз :)
У вас имена методов с прописной буквы начинаются, а имя типа string со строчной.
Очень странная претензия - если писал код на 3-4 языках, то на синтаксис не обращаешь внимания, а просто к нему привыкаешь и пишешь по конвенции. У разных языков разные конвенции, в этом ничего плохого нет
То что это "Proposal Champion", который пилится оч активно, а по факту - это еще одна супер бесполезная фича которая сильнее засахаривает язык. Сахар ради сахара, вместо того чтобы делать полезные фичи которые ждет комьюнити (например те же трейты "shapes and extensions")
Оркестрация на уровне - запустить всё. А если мне надо например 3 проекта из 10?
Касаемо оркестрации, самое простое что можно сделать - это например комментить все проекты кроме трех нужных. А еще, если у тебя например есть 2 разных частых конфигурации запуска (конкретных 3 проекта и конкретных 5 проектов) - то можно сделать два разных AppHost проекта под разные конфигурации
Хороший вопрос. Касаемо деплоя - как мне кажется опыт будет напоминать деплой через Vercel - да, вроде как есть другие облака, можно настроить по-своему CI-CD, но при этом тебе вообще ничего настраивать не нужно, не нужно шарить в инфре. Как минимум для раскатки и тестирования MVP звучит как очень удобная штука
По поводу телеметрии - в целом мне кажется дашборд как раз и предназначен для локальной разработки, и преследует 3 цели:
1. Не надо настраивать докер-копоузы 2. Не надо поднимать достаточно жирные коллекторы и вьюверы телеметрии, Aspire делает все в хост процессе без поднятия считай 3-4 контейнеров 3. Автоматически настроенные, базовые, но +- полезные дашборды.
ИМХО primary constructor сделан исключительно ради облегчения труда программистов при работе с DI.
Отчасти согласен, отчасти нет
Возьмем один кейс, который забыл в статью включить - валидационная логика в конструкторе, ее негде писать. Если мы захотим сделать исключение при null значениях параметров, нам снова придется делать обычный конструктор, т.к нет init{} блока.
Также, в вашем примере (2-ая секция кода), сервисы не будут readonly. Да, согласен, маловероятно что их кто-то поменяет, но лично мое субъективное имхо, фича должна сразу грамотно проектироваться, чтобы например кейсы с иммутабельностью учитывать
Я бы так не сказал. Во первых, можно сделать по AppHost'у на каджый сервис в репе - можно будет хотя бы для 1 сервиса, получать плюхи аспайра, например для поднятия инфраструктуры
Но еще, есть возможность сделать монорепу на гит сабмодулях - и там уже сделать верхнеуровневый солюшн, в который можно запихать нужный сет проектов, для их запуска
Да ладно вам, это всего лишь шутка была, не воспринимайте это всерьёз :)
Очень странная претензия - если писал код на 3-4 языках, то на синтаксис не обращаешь внимания, а просто к нему привыкаешь и пишешь по конвенции. У разных языков разные конвенции, в этом ничего плохого нет
То что это "Proposal Champion", который пилится оч активно, а по факту - это еще одна супер бесполезная фича которая сильнее засахаривает язык. Сахар ради сахара, вместо того чтобы делать полезные фичи которые ждет комьюнити (например те же трейты "shapes and extensions")
Касаемо оркестрации, самое простое что можно сделать - это например комментить все проекты кроме трех нужных. А еще, если у тебя например есть 2 разных частых конфигурации запуска (конкретных 3 проекта и конкретных 5 проектов) - то можно сделать два разных AppHost проекта под разные конфигурации
Щас глянул, вы правы, буквально 2 недели назад выпустили первый GA релиз - https://github.com/dotnet/aspire/releases
Спасибо, добавил приписку в конце статьи
Хороший вопрос. Касаемо деплоя - как мне кажется опыт будет напоминать деплой через Vercel - да, вроде как есть другие облака, можно настроить по-своему CI-CD, но при этом тебе вообще ничего настраивать не нужно, не нужно шарить в инфре. Как минимум для раскатки и тестирования MVP звучит как очень удобная штука
По поводу телеметрии - в целом мне кажется дашборд как раз и предназначен для локальной разработки, и преследует 3 цели:
1. Не надо настраивать докер-копоузы
2. Не надо поднимать достаточно жирные коллекторы и вьюверы телеметрии, Aspire делает все в хост процессе без поднятия считай 3-4 контейнеров
3. Автоматически настроенные, базовые, но +- полезные дашборды.
Отчасти согласен, отчасти нет
Возьмем один кейс, который забыл в статью включить - валидационная логика в конструкторе, ее негде писать. Если мы захотим сделать исключение при null значениях параметров, нам снова придется делать обычный конструктор, т.к нет init{} блока.
Также, в вашем примере (2-ая секция кода), сервисы не будут readonly. Да, согласен, маловероятно что их кто-то поменяет, но лично мое субъективное имхо, фича должна сразу грамотно проектироваться, чтобы например кейсы с иммутабельностью учитывать