Форум 'Архитектура программного обеспечения' на RSDN

Отмена перехвата консоли дочернего процесса

Sun, 18 Jan 2026 12:03:56 GMT

Коллеги, всем привет. Случайно возник вот такой вот архитектурно-философский вопрос.
Сценарий: консольная программа А использует в работе консольную программу Б.
При этом есть два под-сценария:
1. К моменту старта А программа Б уже запущена. Тогда она торчит на каком-то порту 127.0.0.1, программа А подключается туда и делает всё необходимое.
1. К моменту старта А программы Б нет. Тогда А должна сначала запустить Б, и уже потом подключиться.
Нюанс — в том, что после окончания работы А программа Б должна продолжить свою работу ещё какое-то время.
И при этом нам бы хотелось помочь пользователю диагностировать неполадки запуска программы Б.
Сама Б пишет всё, что с ней происходит, в консоль и в лог-файл.
Так что если бы пользователь сам запускал Б, то он бы увидел вывод Б в консоль, и если ей что-то мешает запуститься — там была бы диагностика.

Ок, А в случае если запускает Б, то перехватывает её stout/stderr, и транслирует их пользователю.
И вот мне ИИ на эту тему говорит: постой, но когда А выйдет, а Б останется работать, то попытки Б писать в консоль могут приводить к E_PIPE.
На вопрос "и чо делать", ИИ предлагает перестать читать консоль Б, а вместо этого tail-ить лог-файл Б.
Но юмор в том, что одна из возможных причин неудачи старта Б — отсутствие прав на запись в дефолтный каталог лога

В связи с чем, собственно, вопрос — есть ли кросс-платформенный способ аккуратно отключиться от stdout дочернего процесса?

[Clean Architecture] Как доставать настройки эндпоинта из БД

Wed, 10 Dec 2025 18:26:56 GMT

Как известно, в чистой архитектуре, есть три вида компонент:
— input adapter (например, эндпоинт http api)
— use case c логикой приложения
— output adapter (например, repository БД)

Обычно последовательность вызовов такая: input adapter -> use case -> repository

Но что делать, если некоторые настройки для input adapter находятся в БД, т.е. для работы input adapter нужно получить данные из repository

Примеры:
— проверка идемпотентности (ключи хранятся в БД)
— фиче-флаг, отключающий эндпоинт (флаг хранится в БД)
— проверка прав доступа (права доступа хранятся в БД)
— rate limiter хитрый (настройки хранятся в БД)

Варианты, как я вижу:
— перенести логику проверки из input adapter в use case. Минус — логика приложения может загрязняться деталями инфры
— ходить за настройкам из input adapter напрямую в репозиторий. Минус — на каждый вызов будет две транзакция — для получения настроек и для выполнения use case (хотя одна может быть к RO, вторая к RW)
— делать псевдо-юскейсы для получения настроек. Минус — те же, что и в предыдущем пункте.

Как делать лучше/проще/понятнее?

API vs ABI

Sun, 07 Dec 2025 07:59:13 GMT

А в чем отличие? Это типа если пишешь библиотеку в стиле С — то есть без всяких классов — это АБИ? То есть будет цепляться к любому языку и платформе? А если классы чисто для конкретного языка, то АПИ?

Что если не разделять строго dto, entity, bo...

Fri, 28 Nov 2025 17:47:22 GMT

Вопрос такой.

Вот, обычно делают слои и на уровне каждого слоя свои объект — для строгого разделения. А потом мапперы между слоями.

И у меня сейчас проект, который нужно дорабатывать. Там этой парадигмы разделения не придерживались строго, так что в ui проникают как dto, так и entity. Проект пока не большой, около 25 тыс. строк кода, т.е. за пару-тройку дней можно разделить и добавить мапперы.

Но задумался — а какие реальные бонусы? Вот что пишет зазнайка:

Если использовать DTO в Домене: Ваша бизнес-логика становится зависимой от API-контрактов. Если фронтенд попросит переименовать поле в JSON для удобства отображения, вам придется менять это поле в бизнес-логике, что может повлечь ошибки в расчетах. Внешний мир начинает диктовать правила внутреннему.

Если использовать Entity в Домене: Ваша бизнес-логика зависит от схемы базы данных. Если вы решите денормализовать таблицу для производительности или сменить PostgreSQL на MongoDB, вам придется переписывать бизнес-правила.

Правило архитектуры: Зависимости должны быть направлены внутрь. Слой Домена (бизнес-логика) должен быть самым стабильным и не зависеть ни от Базы Данных, ни от UI/API.

Но на практике вот что. Если что-то нужно добавить в UI — можно использовать расширения/mixin. И что? Никакой сложности не добавляет.

Если что-то изменилось в API — то один хрен нужно менять все слои. Но если добавилось новое поле и мы его не используем — то и в текущей схеме ничего не сломается.

Если изменилась схема хранения данных, к примеру переименовали поле — то сейчас нужно в двух местах переименовать — в entity и в ui, где этот entity напрямую используется. Если добавим мапперы — легче не станет.

Далее. Если добавим тесты и фейковые реализации сервисов — то что мешает в этих фейковых реализациях использовать уже существующие классы для объектов, ведь у них есть конструктор...

По этому как бы, получается, есть вера что нужно разделять — но нет реального смысла.

Репозиторий. Как сделать поиск с исключением

Thu, 06 Nov 2025 07:00:31 GMT

Здравствуйте!

Есть небольшая программа. Сделана в целом по принципам "внедрения зависимостей" и "чистой архитектуры".

Что надо сделать.

Бизнес-операция (usecase) должна выполнить необычный поиск по Репозиторию неких Сущностей (в нашем случае, сущности — это юридические лица).
Поиск выполняется по нескольким "критериям" поиска. Каждый "критерий" — это произвольный набор полей Сущности и их значения ("Поле" — "Значение").
Например:
— Критерий-1: "краткое название" = "Ромашка", "ИНН" = "11223344556600"
— Критерий-2: "юридическое наименование" = "ООО Ромашка", "регион регистрации" = "Москва"
— Критерий-3: "ИНН" = "55667788443322", "КПП" = "6010200001"

Одно и тоже юрлицо может быть найдено по разным критериям. Например, и по первому критерию и по второму критерию.
Особенность поиска в том, что после поиска по какому-то Критерию из дальнейшего поиска исключаются сущности, найденные по этому критерию.
То есть алгоритм должен быть примерно таким:

var repository = new Repository();
var criteria_array = new Criteria[];
// заполнение массива Критериев

foreach (var criteria in criteria_array)
{
    var found_entities = repository.FindByCriteria(criteria);

    ...
    // исключаем найденные сущности из дальнейшего поиска на следующем витке цикла - как???
    ...

    // добавляем найденные сущности в отдельную кеш-таблицу, в которой есть дополнительная колонка "Критерий"
    // для каждой сущности запоминаем критерий, по которому была найдена эта сущность
    cashe_table.Add(found_entities, criteria);
}

process_list = cashe_table.GetAll();
foreach (var entity in process_list)
{
    if (entity.search_criteria.dostovernost = 1)
        algorithm1(entity);
    elseif (entity.search_criteria.dostovernost = 2)
        algorithm2(entity);
    ....
}

Пример. Предположим, в БД есть юридическое лицо со следующими полями:
— "юридическое наименование" = "ООО Ромашка"
— "краткое название" = "Ромашка"
— "регион регистрации" = "Москва"
— "ИНН" = "11223344556600".
Это юридическое лицо может быть найдено по Критерию-1 и по Критерию-2.
Однако, нам нужно, чтобы после нахождения по Критерию-1, это юрлицо не попало в выборку по Критерию-2.
То есть, найденные юрлица исключаются из следующих поисков. То есть это постоянно "сужающийся" поиск.

Объясню зачем нужен такой "сложный" поиск.

Грубо — в зависимости от того критерия, по которому отобраны сущности, выполняются разные обработки над выборками.
У каждого критерия есть признак "вес достоверности".
Например, самый "достоверный" — это Критреий-1. Юрлица, найденные по этому критерию являются "достоверными" и они обрабатываются по одному алгоритму.
Юрлица, найденные по следующему критерию, менее достоверные, их надо обрабатывать по алгоритму-2. И т.д.

Проблема в том, что результаты поиска по каждому критерию пересекающиеся.
То есть одно и тоже юрлицо может попасть в выборку и по Критерию-1 и по Критерию-2 и по другим Критериям.
Но обработано юрлицо должно быть по наиболее "достоверному" Критерию и соответствующему алгоритму.
То есть, если юрлицо попало в выборку по более "достоверному" Критерию-1, то оно должно быть обработано по Алгоритму-1. Нет смысла рассматривать это юрлицо по другим Критериям. Поэтому из поиска по другим Критериям это юрлицо надо как-то исключить.

Вопрос: как при поиске по следующему в массиве Критерию-(n) "отсечь" из результата поиска те сущности, которые были найдены при поиске по предыдущим Критериям?

Была мысль сделать это "топорно": сначала читаем все сущности во временную таблицу, в которой есть поле-"флажок".
Поиск по Критериям выполняем по этой временной таблице. И после поиска по каждому Критерию для найденных сущностей "включаем" этот "флажок".
При поиске по каждому критерию добавляем в условия поиска кроме самого критерия дополнительное условие "флажок" = "выключен".

Но нам этот подход кажется сомнительным.

Посоветуйте плиз как сделать грамотно в русле разделения слоев и "чистой архитектуры".

Что почитать про архитектуру тяжёлых настолок?

Thu, 09 Oct 2025 07:28:00 GMT

CAD, IDE, всякие текстовые редакторы. Можно долго не думать и сделать клиент-сервер, слабую связность везде, но два вопроса:

1. Накладные расходы -> теряется скорость отклика.
2. Как задавать зависимости между компонентами? Например, есть компоненты А и B. Если А работает, то B должен подождать. Но для этого B должен знать про существование А, а это уже не слабая связность. Можнно вввести блокировки ресурсов, конечно, но это банальные варианты из головы, потому что я не проектировал такие штуки никогда.

Что можно почитать на тему проектирования таких штук?

Вопрос о передачи данных между приложениями

Tue, 09 Sep 2025 13:16:50 GMT

Добрый день коллеги!

Возник вопрос в части реализации одной задачки.

Начнем с того, что у нас есть.
В свое время наша фирма разработала по ТЗ заказчика вспомогательную программу, одна из функций которой была работа с аппаратными средствами).
Программа написана на С++. Программу внедрили и сдали клиенту в 1998г. По мере поступления запросов от клиента, функционал проги дописывался.
Теперь о главном. Во время внедрения программы у клиента, часто возникала проблема с данными передаваемыми аппаратным средствам.
Для контроля за передаваемыми данными с нашей стороны была написана DD.DLL, которая записывала лог передаваемых данных(в dd.dll только одна функция csr_DbgWriteData(char*).
В функцию передается строка с данными). При запуске программы, программа ищет DD.DLL, динамически ее загружает и записывает данные в файл.

Теперь о проблеме
Часть ошибок нашли и исправили. Но осталась группа ошибок которые периодически "вылазят" еще, и которые можно выявить только анализируя принимаемые и передаваемые данные аппаратуре.

Что хочется сделать
Хочется написать отдельную программу, которая в реальном времени получает внутренние данные из нашей DD.DLL(т.е. из нашей основной программы). Проводит анализ полученных данных и визуализирует полученную информацию.

Что у нас есть, что можем, как хочется сделать
Мы можем передать указатель на класс, который содержит внутренние данные программы в нашу функцию (перепишем функцию csr_DbgWriteData(char*, CCSR*) )
Закидываем нашу DD.DLL в каталог программы.
Запускаем приложение клиента. В момент передачи и приема данных находим DD.DLL динамически ее загружаем. По необходимости вызываем DbgWriteData. После завершения процесса обмена данными выгружаем нашу DLL.
Класс CCSR содержит данные, многие из которых являются указателями на классы или структуры данных(собственная реализация LIST).

Вопрос
Как наилучшим образом организовать передачу данных между процессами(между основной программой(а точнее сказать DD.DLL) и новым приложением) с учетом что это указатели на данные?
Причем разработка дополнительной новой программы будет вестись на Visual Studio 6.

Как лучше задизайнить?

Sat, 06 Sep 2025 04:29:14 GMT

Есть несколько огромных структур данных. И граф, каждый нод которого или генерит одну из таких структур или как-то принимает эти структуры от других нод, что-то меняет в них, может сливает несколько в одну, или разделяет и отдает на следующие изменения.

Еще важный момент — в каждой ноде данные лежат не кусками по памяти, а сплошным куском. Они в видюху перебрасываются.

Штука в том, чтобы малейшее изменение в одной из нод мгновенно бы отображалось в зависящих от нее нодах.

Копирование всего и вся и распространение сигналов на изменения — крайне неэффективно.
Если делать через ссылки на данные — нарушается условие связности данных.

Как быть?

Глобальное состояние приложения - хорошая ли идея?

Sat, 06 Sep 2025 02:54:24 GMT

Вот, обычно работаю с бекэндом, но последние несколько месяцев завязался с приложением Flutter — т.е. фактически это фронт.

И как-то такая хорошая мысля пришла опосля — а было бы здорово иметь единственный глобальный объект, который представляет весь срез данных (текущий) для UI. Т.е. все те данные, которые могут быть видимы пользователем через формы. При этом часть данных может быть не загружена и т.д.

Начал делать стандартным способом через flutter_bloc — много отдельных объектов состояний — для каждой формы свое состояние (а то и несколько для разных частей формы). И глобально они никак не объединены. Якобы считается что это лучше, т.к. божественный объект (God object) это плохо.

Но на самом деле понял как было бы здорово иметь единый объект структурированный, который отображает все UI — все возможные открытые формы (если не открывали или закрыли навсегда — то конкретное поле пустое).

Сначала показалось плохой идеей, вроде там много всего будет. А на самом деле не так много. Вот даже на примере этого сайта — много ли тут форм? Всегда будет одна и только одна форма для отображения списка сообщений (если открываем новую вкладку/окно — то это отдельный объект состояний а новое сообщение пишем в той же вкладке). Всегда будет одна и только одна форма для отображения текущего сообщения.

Т.е. фактически ну пусть даже 25 полей будет в этом классе (дерево список форумов, текущий форум, текущий список сообщений, текущее сообщение и т.д.). 25 это не много. Да даже 50 полей не много, и 100 норм. Но это очень очень редко какая прога будет иметь так много форм разных типов, скорее будет всего 10-15 полей в среднем (естественно — внутри них свои сложные объекты или списки таких объектов).

Плюс этого всего: сразу видна структура данных приложения. И когда одни данные связаны с другими — ты сразу в одном месте это видишь и можешь обновить связанные данные.

Естественно в состоянии нет ничего связанного с UI — ни виджетов ни вспомогательных UI-текстов.

Минус кажущийся — что много данных будет в этом объекте. А на самом деле нет — даже 1 Мб. редко будет (а что такое 1 Мб для современного телефона даже с минимумом 4 Гб. ОЗУ). Данных много не будет, т.к. храните только текущий срез как бы, текущую одну страницу, которую видит пользователь. То что уже не актуально — подчищаете.

Плюс — у вас как бы справочник всех данных, которые могут быть и связаны и изменение одного требовать обновления другого. Все как на ладони как бы.

Применяете ли? Думали ли об этом?

Про паттерны управления UI

Tue, 05 Aug 2025 11:51:04 GMT

Вот, саму верстку форм вроде обсудили. Лучшее к чему пришло человечество можно назвать: декларативный UI с функциональной интеграцией.

Это все самые передовые фрейморки — такие как Flutter, Jetpack Compose, SwiftUI, React. Т.е. все самое передовое и современное — авангард вертски можно сказать. Чистый декларативный дедовский подход не удобен и существует только как легаси.

Что же касается управления этим UI — то что все-таки лучше на ваш взгляд?

Подход	Часто используется в
MVC	ASP.NET, Django, Ruby on Rails
MVP	Android (раньше), WinForms
MVVM	WPF, Xamarin, Flutter
Redux / UDF	React, Angular, Flutter
BLoC	Flutter
Elm / TEA	Elm, Flutter
Clean Architecture	Любые масштабируемые проекты

Вот, поработал с BLoC. Вроде норм, но даже банальный диалог для подтверждения действия — как бы уже добавляет лишней работы. Т.е. прямо в логике (в bloc диалог вызвать нельзя), значит нужно добавить доп. состояние — требуется отобразить диалог, потом событие от диалога, потом обработку события и т.д. Как бы нет той простоты — когда 1 строчкой отобразил диалог и дальше продолжил выполнять код

Что вы используете и что лучшее на ваш взгляд?

Валидация на фронте

Thu, 19 Jun 2025 09:03:40 GMT

Есть b2b приложение react, в нем есть несколько достаточно сложных форм. Раньше считалось что бизнес логику на фронте лучше не светить,
но вот тут напращивается некоторая валидация на фронте.
Вопроса 2. На фронте что допустимо валидировать, а что нет?
Какие то есть гайды как валидировать на фронте: паттерны, готовые либы или достаточно вызвать на фронте сделать метод Validate куда передать модель которая пойдет на бэк?

Побочка микросервисов или неверный дизайн?

Mon, 19 May 2025 06:29:25 GMT

Тут буквально за пару недель в 3 популярных сервисах столкнулся с неактуальностью данных, а после знакомства с микросервисами понял, что такая вещь там нормально.
у тинькова в приложении при переводе на скрине перевода текущая сумма — сумма перевода != остатку (не учитывалась сумма последней операции)
у озона в заказе неверно показывалась дата доставки на странице заказов, но если перейти в страницу заказа самого то всё корректно показывалось
на sports.ru вчера вот вчера матч Ростов — Зенит показывал 0 — 1 но показывались голы как Зенита так и Ростова, но гол Ростова был отменен, но он висел больше 10 минут на странице даже после ф5.

собственно, получается пользователи думают баги, а по факту просто надо к этому привыкать?

Про обработку ошибок - типовые решения

Sun, 20 Apr 2025 11:28:02 GMT

Задумался об идеологически правильной обработке ошибок (исключительных ситуаций) в приложениях для обычных пользователей.

Конечный итог ошибки может быть таким:

1. Подсветить поле с неверно введенными данными. Самый мягкий случай, когда ошибка ввода данных. Нужно сделать без перехода и диалогов.
2. Отобразить пользователю диалог модальный, когда ошибка важная и требует чтобы пользователь увидел.
4. Отобразить всплывающее окошко. Когда ошибка не важна, скрывать будет не верно (хотя бы для целей отладки и светлого будущего программы), но и она особо погоды не строит.
5. Перевести пользователя в оффлайн-режим. К примеру, если нет подключения, но программа может работать в оффлайн.
6. Заставить пользователя пройти повторную авторизацию (переадресовать на форму входа). Если данные аутентификации отозваны, устарели и пр. Сюда же относим прочие переадресации на формы для обязательного ввода данных (а может быть и не обязательные).
7. Просто записать данные в лог/удаленный лог.
8. Ничего не делать — проигнорить, но оборвать текущую операцию.
9. Возможно — удалить текущую базу данных ввиду ее повреждения (если база не критична) или отобразить форму невозможности продолжения работы ввиду повреждения базы.
10. Попытаться устранить проблему автоматически — как-то устаревший формат файла — провести приведение к новому формату.

Итого — дофига разных вариантов какие типы реакций могут быть.

Фактически нужно помнить что каждая КАЖДАЯ операция может либо завершиться успешно — либо с ошибкой. Причем нужно правильно отреагировать — выбрать какой из 10 вариантов применить.

Есть типовые проблемы, которые могут возникнуть в любом приложении — но очень редко и маловероятно. К примеру, что если я выйду из RSDN, но форму с сообщением не закрою. Потом войду под другим аккаунтом и отправлю сообщение. Под каким пользователем оно опубликуется — под новым или под старым? А ведь я отвечал на сообщение старого пользователя, там от его имени все. Отож. Вывод:

Каждая операция должна проверять под каким пользователем она была начала и если пользователь в процессе операции изменился — то оборвать работу (или даже откатить изменения).

Благо что все эти проблемы возникают не так часто, можно об этом не думать, иначе архитектура усложняется на порядок.

Выход из однопользовательской программы не так прост...

Fri, 18 Apr 2025 06:33:56 GMT

Допустим есть программа, в которой может быть залогинен только один пользователь, т.е. нет переключения между аккаунтами — только Вася или Петя, но не оба одновременно.

Вроде все просто — вошли, загрузили данные, отображаем.

При выходе — просто удаляем данные и все тут.

Но дьявол как всегда в деталях...

Во-первых, если пользователь не нажимал явно "выйти" но по каким-либо причинам доступ данным не возможен (пользователь изменил пароль или удалил приложение из доверенных) — данные удалять не стоит, но при этом нужно перейти на страницу повторного входа. Данные же нужно сохранить, т.к. скорее всего пользователь просто перезайдет.

И тут сразу нюансы... Если мы данные не удаляем — то пользователь ведь может зайти под другим аккаунтом. Уже сразу нужно сравнить его данные или новый пользователь.

Далее...

При выходе нужно отписаться от оповещений как минимум. Иначе оповещение придет а пользователь не вошел. Глупо.

Еще далее. Фоновые задачи. Пользователь мог выйти, но при этом фоновую задачу вы не остановили. Данные удалили — а фоновая задача об этом не знает, т.к. исполняется в отдельном изоляте — она подумает что ничего не изменилось и сохранит некие новые данные для текущего пользователя. Значит обязательно остановить все фоновые задачи, дождаться остановки — и уже тогда удалять.

Но и еще. Остановили фоновые задачи — а если это не фоновая а запрос пользователя, который выполнялся дольше обычного? При этом он удалил базу, потом пришел ответ на запрос. Ну ок, можно блокировать запись в базу. Но! А что если вы создали новую базу (сняли блокировку) — и тут приходит старый ответ на запрос? Опаньки...

Или же умнее не смотря на то что пользователь может быть только один — делать вид как будто приложение поддерживает много-пользовательский режим — для каждого пользователя создавать свою базу данных а в общей конфигурации только указывать какой пользователь активен?

Казалось бы мелочь — но на практике как всегда множество нюансов...

Помогите правильно спроектировать микросервисное приложение

Thu, 20 Mar 2025 14:46:47 GMT

Привет всем.
Как-то только в теории читал про микросервисы, но вот новый проект планируется небольшой и хотел как раз попробовать микросервисы тут.

Первое что хотел сказать, что везде пишут микросервисы это где много команд часто или много функционала. В этом проекте ни того ни другого не будет,
но зато скоп определен четко и подумал прекрасная возможность потренироваться, чтобы потом уверенее пробовать в большом проекте.
Тут я понимаю, что проще было бы сделать монолит, но для обучения вполне годный вариант?

Второе и собственно основное я так понял из книг, что самое сложное это определить границы сервисов. Вот прошу тут помощи как нарезать на сервисы и базы?

Приложение: — Система контроля доставок грузов в разных странах (стран 10).
— Юзеры заходят по user/pswd и система определяет страну и подгружает данные этой страны. Новый юзер сам может зарегаться по логину выданному ему и восстановить пароль.
— В системе будет 4 роли: sysadmin, admin, manager, driver. В каждой стране свои пользователи. Один пользователь = 1 страна.
— Сами заказы поступают в эту систему из другой. В этой надо только мониторить и делать разные действия если доставка задержалась или не приехала.
— В каждой стране много складов и поэтому когда заказы поступают в систему то они сразу попадают на нужный склад и спец алгоритм распределяет на водителей.

— sysadmin управляет только техническими настройками разными (кому когда отчеты отсылать, как в системе заводить оптуска, сколько часов в сутки можно работать, заводит праздники), остальное всё только в режиме просмотра видит.
— admin видит всё, не может только технические настройки менять. Следит за водителями, чтобы они всрок доставляли всё — по юаю специальному, вносит отпуска, больничные их, ставит им рабочее время. Если водитель увольняется — удаляет изи системы.
— manager следит за водителями своего склада только, может посмотреть по всем своим водителям информацию и по всем доставкам, но менять не может
— driver видит только по себе все сделанные доставки и предстоящие. Каждый раз когда он начинает и заканчивает доставку то в системе нажимает Start delivery\End delivery. Если доставка не укладывается в
предполагаемые сроки то пишет к доставке комментарий почему не успел

Итого что по функционалу:
Sysadmin — логин в систему, управление настройками, праздниками и просмотр всего.
Admin — логин в систему, cледит за водителями, чтобы они всрок доставляли всё, вносит отпуска, больничные их, ставит им рабочее время. Если водитель увольняется — удаляет изи системы.
Manager логин в систему, следит за водителями своего склада только, может посмотреть по всем своим водителям информацию и по всем доставкам
Driver логин в систему, видит только по себе все сделанные доставки и предстоящие. Каждый раз когда он начинает и заканчивает доставку то в системе нажимает Start delivery\End delivery. Если доставка не укладывается в
предполагаемые сроки то пишет к доставке комментарий почему не успел

Третий вопрос. Если без докеров то как настроить этот набор микросервисов? тут их немного будет и читал что можно настроить без докер контейнеров если что.

Современные тренды

Thu, 20 Feb 2025 07:34:36 GMT

Всем привет!

Планируется внутреннее приложение (.net core/react + mssql), доступ будет по АД. OS: не точно, но планируется винда
Какие нынче тренды?

что интересует:

1. максимально простое разворачивание. Сейчас в другом проекте из гитхаба из нужной ветки вручную создается через дженкинс билд и деплоится на нужный стенд и накатываются миграции.
Хочется чтобы билды сами создавались и миграции накатывались. Как такое организовать? Или может есть варианты лучше сейчас?
2. первичный деплой максимально простой. а то часто бывает локально всё работает, а на прод деплоишь первый раз и пляшешь там с бубном. Я так понимаю докер решает эти проблемы? локально настроить и потом можно просто его скопировать на нужный сервер, просто поменяв нужный конфиг?
сразу вопрос по докеру. там просто зайти на hub.docker зайти можно или есть варианты лучше?
3. как настроить базы, чтобы если один разработчик поменял разработческую базу (удалил столбец к примеру) и не запушал еще изменения другие могли работать, а не ждать пока изменения попадут в гит?
думал, в идеале, иметь локальные базы каждому разработчику, но тогда вопрос как настроить репликацию мастер данных (в системе много мастер данных, а их заливают в прод)

4. дженкинс лучше иметь один на компанию или под разные проекты свой?
5. очень много слышал про trunk development. как он? сейчас просто каждый в своей ветке делает (часто фронт с бэком в одной) и потом сливают и потом ручками делают деплой и ручками меняют версию

MongoDb vs Postgres Jsonb

Mon, 17 Feb 2025 21:22:51 GMT

На новом проекте проекте предлагают использовать 2 СУБД PostgreSQL для всего и монгу для неструктурированных данных.
Мне не нравится идея хранить данные в двух бд и их поддерживать.
Я бы попробовал использовать в последнем PostgreSQL 17 отдельные таблицы с полем JSONB и при этом для индексирования можно часть полей документа положить рядом в таблице.

Монга имеет хорошее горизонтальное масштабирование, но до этого проекту нужно еще дожить. На постгресе тоже можно сделать кластер. Если будет свсем тяжко, то таблицы с jsonb можно вынести в отдельную бд и на отдельные сервера. Или же партиционирование прикрутить.

Кто-то так делал? Это окупит усложнение проекта за счет использования двух субд?
Можно конечно сделать микросервисы, где один будет отвечать за монгу, а второй за документы в постргресе, но это все отчеты и статистику придется делать на клиенте или в еще одном сервисе интеграции документов из двух бд.

Best practices для retry

Tue, 11 Feb 2025 11:04:55 GMT

В системе имеется вызов стороннего API, по https, может быть как эндпоинт стороннего поставщика, так свой собственный сервис.
Как известно, https вызов может завершится неудачно, и часто рекомендуется повторять попытки несколько раз, даже термин такой придумали как resilient http calls.
А какие best practices вообще по этому поводу существуют, сколько раз повторять попытки, для каких кодов возврата и прочее

Паттерн программирования для обновления UI при Stale-while-r

Sun, 19 Jan 2025 12:57:29 GMT

Я подозреваю, что изобретаю велосипед, что проблема не нова как минимум, в мире онлайн-игр.

Перед клиентом поставлен кеширующий прокси, который передаёт запрос на бек, но, если такой запрос уже был, то он отдаёт сразу из кеша. Это позволяет аппликухе выглядеть быстрее, чем если она бы дожидалась пачки запросов со всеми причитающимися нетворк лагами.

Ничто в мире не бесплатно. Плата здесь — аппликуха получает слегка подгнившие, иногда совсем некорректные данные.

Что я думаю, как это адресовать.
1) Хук в аппликухе по URL заглядывает в кеш у прокси, считывает дату данных и само тело- если оно существует и если дата не превысила срок годности, потому что если привысила- тогда прокси заставит аппликуху дожидаться ответа с бека в любом случае.
2) Если данные существуют в кеше и ещё не совсем протухли, тогда записывает в свой собственный аппликуховый LRU кеш объект и его дату стухания из прокси-кеша и запускает таймер скажем, на 10 секунд.
3) Через 10 секунд по таймеру, по одному, достаёт key-value в аппликуховом LRU, и сверяет дату стухания сохранённую с датой стухания в кеше. Если в кеше больше старой даты нет — выбрасывает key-value и переходит к следующему. Если в кеше старая дата стухания есть и она равна сохранённой в аппликуховом кеше — тогда переходит к следующему key-value.
Если в прокси-кеше дата стухания больше, чем сохранённая в аппликуховом, тогда выбрасывает из аппликухового кеша дату и объект, и сравнивает (deep equals) объект аппликухового кеша с объектом прокси кеша. Если объекты отличаются — тогда извещает подписчиков, что какие-то данные подгнили и нужно данные перезапросить с бека и обновить состояние аппликухи.
4) Если аппликуховый LRU непустой — снова запускается таймер на 10 секунд в пункт 3).

Вопрос- это слишком закручено и есть более прямые пути? есть какой-то паттерн проектирования, который описывает подобную оптимизацию отзывчивости приложения путём скармливания потенциально несвежих данных, не дожидаясь ответа с бекенда?

Сложная выборка

Fri, 13 Dec 2024 13:07:55 GMT

Привет

Есть приложение .net + mssql и есть таблица с 50 полями и нужно сделать выборку из этой таблицы на основании фильтра который состоит из 15 параметров (поля этой таблицы)
Можно конечно сделать перебор всех параметров фильтра типа

if (filter.Param1 != null)
   context.Entities.Where(a => a.Param1 = filter.Param1)
if (filter.Param2 != null)
   context.Entities.Where(a => a.Param2 = filter.Param2)

но может есть что-то элегантнее?

Почему так много полей в таблице не спрашивать)