А как СУБД относится к такой вариабельности? Вы случайно не дали фронтендарм возможность сгенерировать 100 джойнов и не насоздавали 10000 индексов по всем комбинациям полей просто потому что "вдруг кому-то понадоибться"? Каждый раз когда я вижу graphql я боюсь такого исхода, как вы его изебгаете?
Открою секрет: если понять что делает код можно по обоим частям, то одна из них написана зря. Программисты стараются писать код так, чтобы он был понятен без комментариев.
Правильные абстракции призваны как раз улучшить читаемость. Они помогают понять как работает программа без изучения абсолютно всего кода. Отсутствие абстракций часто приводит к необходимости зазубрить весь код чтобы понять как работает небольшая его часть. Плохие абстракции делают и это недостаточным.
При этом я соглашусь, что добавление абстракций или дробление кода может ухудшить "отлаживатьмость" то есть поиск мест где были совершены ошибки, в частности если эти самые абстракции протекли.
собственно у меня ощущение, что с graphql мы жертвуем процессом дизайна апи и согласования требований - то есть экономим в краткосрочной перпективе чтобы потом было сложнее это всё поддерживать
А расскажите как вы обеспечивали совместимость gql апи при изменениях структуры данных в хранилище. Если в маппингах я представляю как это делать - под каждый конкретный кейс адаптируем запросы, то в случае больших возможностей gql мне это кажется более сложным
Так же хотелось бы подробнее узнать за счёт чего gql у вас выиграл в скорости по сравнению с маппингами.
На самом деле зависимости в FastAPI - это как фикстуры в pytest, наверное, самая близкая аналогия.
И да и нет. pytest - как раз пример хорошего, но специализированного IoC конетйнера. В нем есть несколько скоупов (что-то живет всё время, что-то для группы тестов, что-то на время одного теста), изоляция неймспейсов при поиске фикстур (фикстуры одного модуля не мешают другому), отложенное связывание (вы используете имя фикстуры, а не ссылку на неё). В фастапи этого практически нет, а dishka больше похож - есть и вложенные скоупы и изоляция с помощью выделения компонентов, хотя ввиду специфики, устроено чуточку по другому. Но соглашусь, всё это контейнеры с чуть разными возможностями.
Ну вот function-scoped зависимости финализировать как раз самое важное на мой взгляд. Приложение может никогда не перезапускаться или умирать только под SIGKILL, а всякие соединения, скрытые за абстракциями, возвращать в луп приходится регулярно.
Про громоздкость API грустно слышать, потому что количество разных сущностей на порядок меньше чем в dependency-injector. Знай дергай себе provide с указанием скоупа, а потом тот же inject. В том время как в dependency-injector десятка два видов фабрик и даже не знаешь какую когда юзать. Возможно дело в сложном квикстарте, если есть советы как улучшить - буду рад услышать
Задача IoC-фреймворка вообще не в том чтобы у вас появился DI, задача фреймворка - облегчить конструирвование цепочек объектов, когда вы уже обмазались DI. Фреймворк - это вспомогательный инструмент, уменьшающий количество механической работы когда вы уже вступили на путь "хочу инжектировать объекты туда сюда".
То есть, мы изначально решаем использовать внедрение зависимостей для каких-то целей - подмены реализации, конфигурирование объектов, скрытие тразитивных зависимостей от места использования, управление жизненным циклом. Дальше это логично отделяется от основной логики - мы получаем самописный контейнер (а кто-то получает сервис локатор, что про другое но на самом деле связано). И вот тут мы уже можем неплохо автоматизировать его и заюзать фреймворк.
DI это не только про смену реализаций, это ещё и про управление жизненным циклом и умение пробросить параметризованные объекты без протаскивания этих параметров по всем слоям.
Что же касается 2 реализаций, они часто есть - для теста и для прода. Вопрос не про сложные абстракции, вопрос про отделение контрактов от деталей, когда приложение растет, это становится полезным.
В защиту dishka скажу, что с ним вы не привязаны к fastapi и можете делать какие-то вещи, с которыми у фастапи есть проблемы. То есть это универсальное решение, которое вы можете использовать с любым фреймворком (нам же не всегда fastapi хватает, иногда и grpc хочется)
Насколько я помню, в dependency injector финализация как раз сделана очень ограниченно - мы можем финализировать только синглтоны (через Resource), либо при использовании inject забыв про финализацию транзитивных зависимостей.
На мой взгляд, dependency-injector - это очень неудачное решение для контейнера не потому что разработчики перестали его поддерживать, а с точки зрения дизайна API. То есть все клоны будут обраладть теми же пробелмами: слабый контроль жизненного цикла объектов, необходимость ссылаться на конкретный класс контейнере там где мы хотим просто иметь зависимость, неявная передача контейнера через глобальные переменные.
Посмотрите внимательнее на dishka, тут все работает чуточку по другому и я верю, что оно дает больше возможностей и контроля, может и вам зайдет
Так не достать, а передать. =) Прям в инит сервиса/интерактора передать условный DAO. Соответсвтенно в хэндлере никаких сесиий, только инстанс сервиса, а контейнер уже всё связывает друг с другом. Пример есть в документации https://dishka.readthedocs.io/en/stable/quickstart.html
Насчет вкуса конечно верно, но к разработке своего контейнра мы пришли с несколькими требованиями. В частности: * контейнер должен уметь финализировать объекты после использования и появление таких промежуточных объектов не должно менять логику работы с целеым * контейнер должен уметь выдавать одни и те же объекты если их запрашиваю в пределах одного "скоупа"
С обоими пунктами у dependency-injector все очень странно. То есть мы можем использовать его декоратор `@inject`, но при этом придется вручную перечислять в функции, что мы финалиизруем, хотя это вообще могут быть транзиитвные завимисоти. Как он переиспользует объекты тоже не оченвидно, так как понятия скоупа фактически нет за пределами этого декоратора.
Я надеюсь, все варианты представлены только в образовательных целях для того, чтобы разработчики, встаривающие капчу на свои ресурсы знали о модели угроз. Да?
А проблема в чем?
А в чем профит того что он синглторн если он везде внедряется через DI? В чем отличие от не-синглтона?
А можно пример реально нужного случая? Тот, который по другому не решить (например через DI единственного экземпляра)
То есть, Мальвинские?
А как СУБД относится к такой вариабельности? Вы случайно не дали фронтендарм возможность сгенерировать 100 джойнов и не насоздавали 10000 индексов по всем комбинациям полей просто потому что "вдруг кому-то понадоибться"? Каждый раз когда я вижу graphql я боюсь такого исхода, как вы его изебгаете?
Открою секрет: если понять что делает код можно по обоим частям, то одна из них написана зря. Программисты стараются писать код так, чтобы он был понятен без комментариев.
SOLID вообще не требует DI, btw
Правильные абстракции призваны как раз улучшить читаемость. Они помогают понять как работает программа без изучения абсолютно всего кода. Отсутствие абстракций часто приводит к необходимости зазубрить весь код чтобы понять как работает небольшая его часть. Плохие абстракции делают и это недостаточным.
При этом я соглашусь, что добавление абстракций или дробление кода может ухудшить "отлаживатьмость" то есть поиск мест где были совершены ошибки, в частности если эти самые абстракции протекли.
собственно у меня ощущение, что с graphql мы жертвуем процессом дизайна апи и согласования требований - то есть экономим в краткосрочной перпективе чтобы потом было сложнее это всё поддерживать
А если будет меняться, то тем более - у вас есть хорошее понятное огранчиенное апи. Его менять и обеспечивать совместимость проще
А расскажите как вы обеспечивали совместимость gql апи при изменениях структуры данных в хранилище. Если в маппингах я представляю как это делать - под каждый конкретный кейс адаптируем запросы, то в случае больших возможностей gql мне это кажется более сложным
Так же хотелось бы подробнее узнать за счёт чего gql у вас выиграл в скорости по сравнению с маппингами.
И да и нет. pytest - как раз пример хорошего, но специализированного IoC конетйнера. В нем есть несколько скоупов (что-то живет всё время, что-то для группы тестов, что-то на время одного теста), изоляция неймспейсов при поиске фикстур (фикстуры одного модуля не мешают другому), отложенное связывание (вы используете имя фикстуры, а не ссылку на неё). В фастапи этого практически нет, а dishka больше похож - есть и вложенные скоупы и изоляция с помощью выделения компонентов, хотя ввиду специфики, устроено чуточку по другому. Но соглашусь, всё это контейнеры с чуть разными возможностями.
Ну вот function-scoped зависимости финализировать как раз самое важное на мой взгляд. Приложение может никогда не перезапускаться или умирать только под SIGKILL, а всякие соединения, скрытые за абстракциями, возвращать в луп приходится регулярно.
Про громоздкость API грустно слышать, потому что количество разных сущностей на порядок меньше чем в dependency-injector. Знай дергай себе provide с указанием скоупа, а потом тот же inject. В том время как в dependency-injector десятка два видов фабрик и даже не знаешь какую когда юзать. Возможно дело в сложном квикстарте, если есть советы как улучшить - буду рад услышать
Задача IoC-фреймворка вообще не в том чтобы у вас появился DI, задача фреймворка - облегчить конструирвование цепочек объектов, когда вы уже обмазались DI. Фреймворк - это вспомогательный инструмент, уменьшающий количество механической работы когда вы уже вступили на путь "хочу инжектировать объекты туда сюда".
То есть, мы изначально решаем использовать внедрение зависимостей для каких-то целей - подмены реализации, конфигурирование объектов, скрытие тразитивных зависимостей от места использования, управление жизненным циклом. Дальше это логично отделяется от основной логики - мы получаем самописный контейнер (а кто-то получает сервис локатор, что про другое но на самом деле связано). И вот тут мы уже можем неплохо автоматизировать его и заюзать фреймворк.
DI это не только про смену реализаций, это ещё и про управление жизненным циклом и умение пробросить параметризованные объекты без протаскивания этих параметров по всем слоям.
Что же касается 2 реализаций, они часто есть - для теста и для прода. Вопрос не про сложные абстракции, вопрос про отделение контрактов от деталей, когда приложение растет, это становится полезным.
В защиту dishka скажу, что с ним вы не привязаны к fastapi и можете делать какие-то вещи, с которыми у фастапи есть проблемы. То есть это универсальное решение, которое вы можете использовать с любым фреймворком (нам же не всегда fastapi хватает, иногда и grpc хочется)
Насколько я помню, в dependency injector финализация как раз сделана очень ограниченно - мы можем финализировать только синглтоны (через Resource), либо при использовании inject забыв про финализацию транзитивных зависимостей.
На мой взгляд, dependency-injector - это очень неудачное решение для контейнера не потому что разработчики перестали его поддерживать, а с точки зрения дизайна API. То есть все клоны будут обраладть теми же пробелмами: слабый контроль жизненного цикла объектов, необходимость ссылаться на конкретный класс контейнере там где мы хотим просто иметь зависимость, неявная передача контейнера через глобальные переменные.
Посмотрите внимательнее на dishka, тут все работает чуточку по другому и я верю, что оно дает больше возможностей и контроля, может и вам зайдет
Так не достать, а передать. =) Прям в инит сервиса/интерактора передать условный DAO. Соответсвтенно в хэндлере никаких сесиий, только инстанс сервиса, а контейнер уже всё связывает друг с другом. Пример есть в документации https://dishka.readthedocs.io/en/stable/quickstart.html
Не очень понятно, что вы делаете с msys2. Ваша целевая платформа для сервера windows?
Насчет вкуса конечно верно, но к разработке своего контейнра мы пришли с несколькими требованиями. В частности:
* контейнер должен уметь финализировать объекты после использования и появление таких промежуточных объектов не должно менять логику работы с целеым
* контейнер должен уметь выдавать одни и те же объекты если их запрашиваю в пределах одного "скоупа"
С обоими пунктами у dependency-injector все очень странно. То есть мы можем использовать его декоратор `@inject`, но при этом придется вручную перечислять в функции, что мы финалиизруем, хотя это вообще могут быть транзиитвные завимисоти. Как он переиспользует объекты тоже не оченвидно, так как понятия скоупа фактически нет за пределами этого декоратора.
Я надеюсь, все варианты представлены только в образовательных целях для того, чтобы разработчики, встаривающие капчу на свои ресурсы знали о модели угроз. Да?