Ну про СУБД вы немного заблуждаетесь, на малых объемах данные её возможно будет достаточно, но как только данные станут более существенны прибегают к созданию ещё одной подобной БД — OLAP. При этом проектируют её оптимизированной под специальные запросы.
Ну если вам надо дергать данные с разных хранилищ, то тут ничего не поделаешь, придется делать несколько запросов. Есть конечно вариант хранить все же данные в SQL, но тут необходимо придерживаться нескольких правил, не должно быть связей между таблицами по вторичному ключу у разных сервисов, а также они должны быть с разными схемами. Так можно будет легко разделить данный на две различный базы, если того потребуется.
Если вы про организацию хранилища, то да, это EventSourcing. Тут правда надо понимать что хранилищем может быть и обычная SQL база, тут дело в самом подходе его организации. Насчет Saga паттерна можно почитать здесь.
Есть такая вещь как распределенная транзакция. Но это требует определеногго подхода и при проектировании хранилища. Идея в том, что сервис сохраняет текущее состояние, и ждет подтверждения от другого сервиса(кому было передано сообщение), что и он отработал успешно. Если такое подтверждение получено не будет то будет послано новое сообщение, которое отменяет предыдущее действие. Есть и специальные паттерны для выполнения таких транзакций, например Saga.
Поскольку проект под лицензией MIT, можно попробовать прогнать статический анализатор PVS-Studio, может ещё какие нибудь недочеты можно будет устранить.
Я вот установил на старый ноутбук Fedor-у с GNOME интерфейсом. Первое что не привычно так это отсутствие иконок на рабочем столе, знаю что можно это настроить, но было не до этого. Поигрался с установкой пакет, кажется собирал electrum приложение, ну и несколько раз натыкался на ошибку отсутствия нужных зависимостей в репозитории. Неприятно и проходиться искать нужные зависимости самому. Насколько я понимаю, репозитории федоры проходит модерацию прежде чем попасть туда, так и должно быть. Уязвимости нам не нужны! Как у остальных дистрибутивов с пакетными менеджерами и зависимостями? Потому как собираюсь ставить .net core, а по моему только в 26 версии собираетcя.
Тут надо упомянуть что схема в Avro передается вместе с данными. Поэтому если мы часто гоняем данные и для нас важен размер отправляемого пакета, то Avro не самый лучший выбор.
Большее спасибо за статью, честно говоря думал что Avro умер, впрочем как и Thrift.
Да, так оно. А разве некоторые платформы не устарели? По моему поддержка GCC не настолько важна на данный момент. Лучше направить сил на что нибудь другое.
поддержка асинхронного программирования (async/await)
Как по мне в rust лучше предоставить семейство типов для работы с асинхронностью. async/await лучше оставить более высокоуровневым языкам. Например в с# это модель очень удобна, но достигается путем нескольких абстракции.
Можно возвращать HttpMessageException со статус кодом и описанием. Сосбтвенно ради чего этот тип исключения и был создан. У нас принято все 4xx ошибки возвращать через исключение. Тут зависит от похода, и как мы относимся к ошибкам в бизнес-логике. Я лишь привел пример, метод для валидации можете назвать по другому и реализовать по своему
Скажите, а почему бы не вынести это в базовый контроллер? Одна строчка аттрибута или одна строчка в начале метода? В обоих случая если забудете написать, то валидация работать не будет.
Ментор мой тоже не любит аттрибуты, и предпочитает выносить в базовый контроллер вот такие вот проверки. И уже в самом начале метода вызывать метод из базового класса.
public IActionResult Post(Model model)
{
ThrowIfModelIsInvalid(model);
return View();
}
Таким образом у нас метод становиться статическим, и не надо шаманить с аттрибутами.
Думаете Intel и другие разработчики процессоров сразу же пересядут на Rust? Учитывая что программирование касаемо hardware довольно небезопасно, то сплошь и рядом придётся писать блоки unsafe кода.
Ну если вам надо дергать данные с разных хранилищ, то тут ничего не поделаешь, придется делать несколько запросов. Есть конечно вариант хранить все же данные в SQL, но тут необходимо придерживаться нескольких правил, не должно быть связей между таблицами по вторичному ключу у разных сервисов, а также они должны быть с разными схемами. Так можно будет легко разделить данный на две различный базы, если того потребуется.
Это потому что у нас не было выбора.
Большее спасибо за статью, честно говоря думал что Avro умер, впрочем как и Thrift.
Вот серьозно, зачем это нужно если есть LLVM.
Как по мне в rust лучше предоставить семейство типов для работы с асинхронностью. async/await лучше оставить более высокоуровневым языкам. Например в с# это модель очень удобна, но достигается путем нескольких абстракции.
Скажите, а почему бы не вынести это в базовый контроллер? Одна строчка аттрибута или одна строчка в начале метода? В обоих случая если забудете написать, то валидация работать не будет.
Таким образом у нас метод становиться статическим, и не надо шаманить с аттрибутами.