1. тут правы. пока статья была на модерации, я уже успел прикрутить туда Optimistic Concurrency Control. В репе версия уже с ним, в статье обновлять не стал
2. +\- согласен. можно вынести, чтоб не засорять message
3. тут тоже соглашусь, опять же, пока шла модерация, я выяснил что Read операции стоят сильно дешевле и на этом можно неплохо сэкономить. Начал думать (и делать) в эту сторону, но столкнулся с другой проблемой: как проверить валидность сообщения? ведь входной канал у EDDN не поддерживает авторизации и заслать туда сообщение можно с любой биллибердой сколько угодно раз. Так что кто-то, теоретически, может сильно засорить данные. В EDSM для этого предусмотрен механизм валидации — одно и то же сообщение должно придти минимум от 3-х разных пилотов и, так как там есть аворизация, они могут себе это позволить. Ну а у меня пока upsert с надеждой что сообщение будет перезаписано другим пилотом. Пока разбираюсь что делать.
В EventHub и bulk тоже уже смотрю, как на средство нормально сэкономить, но, опять же, это усложнит валидацию сообщений (если я ее все же придумаю). Если валидации не будет, то можно спокойно делать булки
согласен полностью. для пет-проектов довольно кусаче, но т.к. тоже в интерпрайзе работаю с ажурой — решил попробовать на ней. но и в этом есть свой существенный плюс — при SaaS подходе с программиста спадает вся ответственность за администрирование, поддержку, стабильность, настройку и безопасность инфраструктуры. остается только программировать. кому-то это может показаться плевым делом (поднимать и настраивать VPS-ски и потом их админить), но я не фанат такого дела, так что решил занести в ажуру и не париться.
Боюсь продакшн версию всего этого хозяйства не поднять, так как почти везде используются сервисы Azure: Azure Storage, Azure Functions, даже CosmosDB не поставляется on-premise. Разве что WebJob можно сделать на виртуалке, т.к. это просто dotnet приложение. Для себя\тестирования можно установить эмуляторы всего этого (в статье приводил ссылки на них) и тогда будет работать локально. Но, все же, это эмуляторы и они имеют некоторые ограничения.
Можно и кафку, но, в зависимости от модели: через event hub — ну нет там стольких сообщений (хотя вариант рабочий и я думал на этот счёт), через HDInsights — слишком дорого.
2. +\- согласен. можно вынести, чтоб не засорять message
3. тут тоже соглашусь, опять же, пока шла модерация, я выяснил что Read операции стоят сильно дешевле и на этом можно неплохо сэкономить. Начал думать (и делать) в эту сторону, но столкнулся с другой проблемой: как проверить валидность сообщения? ведь входной канал у EDDN не поддерживает авторизации и заслать туда сообщение можно с любой биллибердой сколько угодно раз. Так что кто-то, теоретически, может сильно засорить данные. В EDSM для этого предусмотрен механизм валидации — одно и то же сообщение должно придти минимум от 3-х разных пилотов и, так как там есть аворизация, они могут себе это позволить. Ну а у меня пока upsert с надеждой что сообщение будет перезаписано другим пилотом. Пока разбираюсь что делать.
В EventHub и bulk тоже уже смотрю, как на средство нормально сэкономить, но, опять же, это усложнит валидацию сообщений (если я ее все же придумаю). Если валидации не будет, то можно спокойно делать булки
Можно и кафку, но, в зависимости от модели: через event hub — ну нет там стольких сообщений (хотя вариант рабочий и я думал на этот счёт), через HDInsights — слишком дорого.