Есть какой-то живой di в расте нынче? посмотрел teloc, shaku

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

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

А что именно вы хотите получить от данного di решения? Сам di контейнер же вроде штука тривиальная, подойдет любая немутабельная структура, из которой торчат нужные зависимости.

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

просто создать немутабельную структуру, например, Depencency, и запихнуть в нее все, что нужно и тянуть из нее все — это не вариант в Вашем случае? P.S. сразу уточнение: мне ответ на Ваш вопрос самому интересен. Я просто уточняю чем простое решение хуже левой зависимости (мертвой в данном случае)

можно, но это по сути будет почти тем же, что я сейчас через шаку делаю, только извлеченное из-под его капота имхо проблема тут как минимум одна - будет один супержирный метод на создание инстанса этой структуры условно говоря, разрастется приложение до 20 модулей (назовем сочетание хендлер-сервис-репа так) это надо будет 20 раз создавать все три сущности вот так и пихать в эту структуру в одном месте некрасиво

как думаете, такой вариант решит проблемы? - создать Dependency структуру, которая держит все зависимости/фабрики и пр. - каждый модуль ожидает свой трейт для зависимостей - структура Dependency реализует все трейты модулей В таком варианте сам модуль ограничен трейтом, но под капотом все равно лежит полная структура Dependency.

God object получился

Такое вообще не получится сделать нормально

А зачем тогда передавать эту dependency и реализовывать ей трейты, если можно передать её поле

у ребят из pointfree.co есть аргументы в пользу такого решения, но это из мира iOS и swift. Структура немутабельная и да, она God object. Зато с точки зрения когнитивной нагрузки все очень просто.

Зато с точки зрения перекрывающихся методов всё очень плохо

И что насчёт чего-то рабочего на этом вот?

возможно я тут не прав и мои аргументы из мира мобайла (iOS/Flutter), но обычно это приводит к тому, что родительский модуль должен получить зависимости для всех потенциальных подмодулей, которые он может порождать

https://github.com/pointfreeco/swift-dependencies -- у этих ребят достаточно грамотно все и есть куча рабочих примеров. Даже если учесть, что это не раст, стоит кмк глянуть в их подход

Не заметил что-то условного проброса импл трейтов наружу

я свой вариант предложил. Сам думаю как это сделать на своем проекте. Потому участвую в обсуждении не чтобы что-то умное ляпнуть, а чтобы самому получить правильный ответ )

Send Sync Clone будут больно бить по рукам

Без Send Sync все равно никуда

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

ambassador не подойдет?

Надо чтобы кто-то повесил атрибуты на все трейты

А вы не рассматривали вариант засунуть пул коннектов в статик переменную через lazy_static и потом уже из любой части бэкенда можно будет использовать эту переменную для получения подключения? Или такой подход в чем то неправилен?

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

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

https://github.com/microsoft/cookiecutter-rust-actix-clean-architecture/blob/main/docs/onion-architecture-article.md Что-то такое получилось?

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

Ну там не только статья в репе, но и темплейт. Думаю показательно, что даже яростные адепты DI - Microsoft не сделали его тут)

ну и пусть если опираться на «так у гугла/амазона/майкрософта», то далеко не уедешь нужно по конкретным случаям судить

Не совсем про это. Уверен, что они очень хотели DI, просто не сумели красиво реализовать на расте, так же как можно это сделать в их шарпе

да, о том и речь, что красивого di в расте я не видел, сколько ни искал думать надо, по другим компилируемым языкам покопаться на предмет примеров и тд

Тут ключевая ошибка в изначальном посыле: "само приложение по привычке поделил на слои контроллер, сервис, репозиторий вот хочу между слоями через DI инжектить". Не надо пытаться реализовывать свои сомнительные привычки из языков совсем другого класса (созданных для безопасной работы дешёвыми и малоквалифицированными разработчиками) в Rust или C++. Тут совсем другой мир. Лучше посмотреть как здесь принято делать. >и хочется что-то аналогичное спрингу в этом плане придумать Не знаю кто как, а я вот наоборот максимально расстроюсь, если в Rust начнут тащить гадости в стиле спринга. >мне вот непонятно что теряют системщики, если в расте появятся более развитые тулзы для того же бэка? Спать меньше станут от религиозной ярости или что? У меня команда пишет на Расте и бэк и фронт и ещё микроконтроллеры (с которыми общается как раз бэк). Причём бэк на порядок сложнее (одно требование реалтайма чего стоит) привычных всем CRUD'ов. Так вот, во всём этом сложном проекте (из множества связанных crate'ов и бинарников, работающих на принципиально разных платформах и общающихся между собой) нигде нет этих ваших десятков никчемных архитектурных слоёв, DI и прочей Java головного мозга. При этом всё работает с отличным быстродействием и код имеет простую и стройную структуру. Так что может это просто кто-то не умеет на самом деле готовить бэк? )

а что по требованиям реалтайма? у вас ОСРВ используется? или имеется в виду реалтайм в обиходном значении?

расскажи пожалуйста про реалтайм на беке. Ни разу не слышал подобного

Реалтайм в настоящем понимание есть в микроконтроллерах и там вообще никаких ОС нет в принципе. А на бэке да, реалтайм в человеческом понимание: отсутствие видимых глазу задержек между переданной командой и отображением её исполнения в транслируемом видеопотоке высокого качества. Но на самом деле реализовать такое даже намного сложнее чем истинный жёсткий реалтайм в МК, потому что сочетание больших объёмов передаваемых данных с нестабильным каналом связи максимально затрудняет задачу.

«Я иду как глубокий старец, узревший вечное, прикоснувшийся к божественному, сам стал богоподобен и устремлён в это бесконечное» (c)

если вдруг было непонятно из контекста, то я писал про вообще, а про конкретный проект. Что в нём имеется область реализации жёсткого реалтайма, но она находится не в бэке. И делается это всё на МК настолько просто, что гордиться там абсолютно нечем. В отличие от "ненастоящего" реалтайма в бэке, где уже требовалась сложная работа.