Давно смотрю за развитием библиотеки, очень интересно даже с точки зрения реализации. Но давно хотел спросить, какие предпосылки были для создания такого решения? Да, я вижу описания фичей, что всё статически, ошибки на этапе компиляции и т.д. Но в реальности, даёт ли это что-то в сумме?
Я хочу сказать, что я давно использую DI, ещё со времён Autofac, потом перешли дружно на решение майков. В различных проектах и кейсах, в монолитах и микросервисах, под нагрузками, под требованиями с низким latency, т.д., но как-то не припомню, чтобы DI был проблемой и вносил заметные задержки. Понятно, что я не получаю зависимости в hot path, в циклах. Но там, где он используется его влияние крайне мизерное, чтобы это стало заметным. Иногда требуется агрессивная оптимизация, тогда приходится чем-то жертвовать, но под нож DI почти никогда не попадет, и таких случаев совсем мало на фоне основных задач бизнес-логики.
Да, из неприятного, это ошибки рантайм. Но они также довольно редкие и фиксятся быстро.
Вот на практике, есть ли живой профит, который прям зарешал?
У нас была ситуация, из приложения на PHP по запросу получали словарь типа { "key1": "value1"...}. И всё было хорошо, пока не случилась крайне неприятная ситуация с пустым словарём. Потому что возвращаться стало вот это [], а не {}. Запросы выполнялись из приложения на типизированном языке, где подобное в принципе не мыслимо, словарь это всегда словарь, массив это массив (с конкретным типом элементов), а int это всегда int. Исправили костылём, но осадочек остался. Подобные решения приветствую, главное чтобы они работали :)
В продакшене дебаг может быть крайне полезен, если есть возможность на время менять уровень журнала, для исследования нестандартных сложных ситуаций. Ещё круче, если есть возможность менять уровень без перезапуска "на лету" и менять его точечно, только на некоторые компоненты.
Необходимо хорошо разбираться в смысле уровней журнала, чтобы не писать лишнего в лог "на всякий случай", а писать только действительно необходимое.
Интересней генерация авто-тестов по спецификациям (сваггер, прото, етс.), слишком много завязано на конкретной реализации в бекенде, слишком большая сцепка. Второй вопрос, да конечно наверное приятно получить +25% "халявного" покрытия, но нет ли тут само-обмана? Если уж тут всё держится на аннотациях, то бекенд на этих же самых аннотациях и должен работать, т.е. тестировать надо всего лишь механизм аннотаций. Например, аннотация, требующая авторизации. Это должно работать уже просто потому, что аннотация добавлена, независимо от реализации метода. Даже если реализация вообще пустая, вызвать метод без авторизации нельзя. Ну или чего-то не понимаю, как будто лишняя работа, в холостую, ради "процентов покрытия", автотесты ради автотестов.
Фанатизм это слепая вера. Поэтому выражение "бывший фанатик" никак не усиливает аргументацию, а только всё портит. Фанатизм это не конструктивная позиция изначально, смена вектора фанатизма ничего не говорит качестве предмета обожания.
Microsoft огромная компания с мировым распространением и влиянием на ИТ. Поэтому так заметны ошибки. Не ошибаться, значит стагнировать. Вспомним количество похороненных технологий Google. Тоже всё через одно место? Видимо вы никогда ни в чём не ошибаетесь.
Java востребована в большинстве случаев из-за тонны легаси, а вовсе не потому что это лучшее решение среди других.
Ну вообще-то есть YARP. А использование обратного прокси необходимо для целей балансировки, отказоустойчивости и безопасности. И можно для этого использовать тот же Kestrel + YARP, работает отлично.
Вот какие задачи мы решали с помощью SignalR без написания каких-то библиотек, с минимум кода:
Таймер времени на сессию пользователя, который ведётся на сервере. В одном проекте у каждого пользователя есть KPI, который считает сколько он работы проделал за время сессии, и ещё этапы работы автоматически закрываются по периодам, либо по количеству работы, и открываются новые. Всё делается автоматически в контексте сессии пользователя.
Запуск длительных обработок, например, построение отчёта. Пользователь запускает операцию, и потом продолжает работать в системе, при этом пользователю отображается прогресс(ы) запущенных операций во время его работы в системе. По завершению любой запущенной операции он может вернуться к ней и посмотреть результат или пошарить другим юзерам.
В Hosted Services есть всё, что нужно. Это фоновый процесс, который может запускать и останавливать задачи, по одному на каждую сессию. Для коммуникации с фоновым процессом можно использовать простейший диспетчер, например, Task Channels, что также идёт из коробки.
SignalR напрямую решает задачу поддержания активной серверной сессии для каждого клиента, так как это требуется для двух-сторонней коммуникации и обмена данными.
Итого, вы не потрудились провести даже минимальное исследование платформы. Это даже не какие-то "левые" библиотеки, это всё идёт в коробке. Но написали очень много кода.
Зачем? :) Ну возможно в этом и есть смысл, возможно действительно что-то из представленного не решает тех проблем, с которыми столкнулись именно вы. Но какие это проблемы?
Разработка ПО это прежде всего инженерная дисциплина. Писать много кода -- это не значит хорошо, чем меньше кода мы пишем для достижения желаемого, тем эффективней наш труд, тем выше его ценность.
Какого-то анализа правда не хватает. Зачем писать свой велосипед на каждый чих? Потому что могу? :)
Я не пытаюсь обесценить ваши труды. Но всё же, какого-то хоть минимального исследования проблемы и существующих решений очень сильно не хватает для полноценной статьи.
Иначе выглядит это так:
-- Смотрите, какой я написал свой логгер / парсер / запускатель задач / etc.. -- А вы в курсе, что уже есть как минимум решения X, Y, Z... решающих ваши задачи? -- А зачем? Чукча не читатель, чукча писатель
Глубоко в детали пока не углублялся, но вот чего я не нашёл в содержании, это какого-то исследование альтернатив, или инструментов, которые можно было бы использовать для достижения той же цели. И, самое главное, чем данное конкретное решение лучше.
На поверхности сразу: SignalR, сессия итак создаётся на каждое подключение и держится до его окончания, разные вкладки можно объединять в группы (например, по user-id) и поддерживать процессы для группы. Чем не подходит обычный IHostedService в связке с SignalR и удержание сессионного CancellationTokenSource?
Если говорить про масштабирование вычислений, а это нам точно понадобится, то почему не Orleans? Как-то грустно, когда бекенд, который хостит апишечеку, должен ещё чего-то в фоне делать, да ещё и с лютейшими ограничениями на прилипание пользователя к конкретному экземпляру.
В общем, вопросов много, ответов мало. Если это просто ради опыта, то опыт безусловно это хорошо, но настоящий инженер перед тем, как изобрести колесо, сначала изучит другие колёса.
Мне кажется, вы с одной темы резко перескакиваете на другую. Ваша оценка деятельности и власти России субъективна, много людей во всём мире придерживаются иной точки зрения, диаметрально противоположной вашей. Да у вас есть право на собственное мнение и множество людей также придерживаются позиции, которую декларируете вы. Много, но не все, и даже не большинство.
Поэтому, это не истина в последней инстанции, и делать какие-то выводы из такой позиции абсолютно некорректно. Дискуссия в таком случае бессмысленна и приводит только к политическому срачу.
Мы говорим о фактах. А факты состоят в том, что не Россия уходит. Её выгоняют, исключают, отключают. Что это может значить для других стран? Очевидные риски. Не будем говорить кто виноват и почему. Важен сам факт.
Оба утверждения не верные. Mapster умеет генерировать код мапперов, работает оно точно также, как и написанный код вручную. Сокращает ли количество рутинного кода? Да. Тут больше ориентируются на принятые в проекте подходы, убеждения лида, и особенности маппинга. Если они по большей части сложные и кастомные, толку не будет. Если они в основном рутинные, перекладывание значений из полей, то профит есть и не малый, если DTO много.
Ну хорошо, кажется я понял о чём вы говорите. Предоставленный токен может иметь более широкую область действия, чем авторизация в одном конкретном бекенде.
Почему бы просто не зашифровать пару access/refresh и положить в HttpOnly? В таком виде токены нельзя будет использовать на других бекендах, а только в конкретном.
На всякий случай, принцип обсуждаемого механизма авторизации в том, что токен выдаётся клиенту. Он предназначен для клиента, как удостоверение, с которым клиент может посещать различные, доступные ему заведения. Вместо решения задачи защиты токена, получается, мы полностью меняем принцип. Поправьте меня, если я не прав.
Давно смотрю за развитием библиотеки, очень интересно даже с точки зрения реализации. Но давно хотел спросить, какие предпосылки были для создания такого решения? Да, я вижу описания фичей, что всё статически, ошибки на этапе компиляции и т.д. Но в реальности, даёт ли это что-то в сумме?
Я хочу сказать, что я давно использую DI, ещё со времён Autofac, потом перешли дружно на решение майков. В различных проектах и кейсах, в монолитах и микросервисах, под нагрузками, под требованиями с низким latency, т.д., но как-то не припомню, чтобы DI был проблемой и вносил заметные задержки. Понятно, что я не получаю зависимости в hot path, в циклах. Но там, где он используется его влияние крайне мизерное, чтобы это стало заметным. Иногда требуется агрессивная оптимизация, тогда приходится чем-то жертвовать, но под нож DI почти никогда не попадет, и таких случаев совсем мало на фоне основных задач бизнес-логики.
Да, из неприятного, это ошибки рантайм. Но они также довольно редкие и фиксятся быстро.
Вот на практике, есть ли живой профит, который прям зарешал?
У нас была ситуация, из приложения на PHP по запросу получали словарь типа
{ "key1": "value1"...}. И всё было хорошо, пока не случилась крайне неприятная ситуация с пустым словарём. Потому что возвращаться стало вот это[], а не{}. Запросы выполнялись из приложения на типизированном языке, где подобное в принципе не мыслимо, словарь это всегда словарь, массив это массив (с конкретным типом элементов), аintэто всегдаint. Исправили костылём, но осадочек остался. Подобные решения приветствую, главное чтобы они работали :)В продакшене дебаг может быть крайне полезен, если есть возможность на время менять уровень журнала, для исследования нестандартных сложных ситуаций. Ещё круче, если есть возможность менять уровень без перезапуска "на лету" и менять его точечно, только на некоторые компоненты.
Необходимо хорошо разбираться в смысле уровней журнала, чтобы не писать лишнего в лог "на всякий случай", а писать только действительно необходимое.
Кто-то нашёл в статье чёткий критерий "качества" перемешивания?
Интересней генерация авто-тестов по спецификациям (сваггер, прото, етс.), слишком много завязано на конкретной реализации в бекенде, слишком большая сцепка. Второй вопрос, да конечно наверное приятно получить +25% "халявного" покрытия, но нет ли тут само-обмана? Если уж тут всё держится на аннотациях, то бекенд на этих же самых аннотациях и должен работать, т.е. тестировать надо всего лишь механизм аннотаций. Например, аннотация, требующая авторизации. Это должно работать уже просто потому, что аннотация добавлена, независимо от реализации метода. Даже если реализация вообще пустая, вызвать метод без авторизации нельзя. Ну или чего-то не понимаю, как будто лишняя работа, в холостую, ради "процентов покрытия", автотесты ради автотестов.
Фанатизм это слепая вера. Поэтому выражение "бывший фанатик" никак не усиливает аргументацию, а только всё портит. Фанатизм это не конструктивная позиция изначально, смена вектора фанатизма ничего не говорит качестве предмета обожания.
Microsoft огромная компания с мировым распространением и влиянием на ИТ. Поэтому так заметны ошибки. Не ошибаться, значит стагнировать. Вспомним количество похороненных технологий Google. Тоже всё через одно место? Видимо вы никогда ни в чём не ошибаетесь.
Java востребована в большинстве случаев из-за тонны легаси, а вовсе не потому что это лучшее решение среди других.
Ну вообще-то есть YARP. А использование обратного прокси необходимо для целей балансировки, отказоустойчивости и безопасности. И можно для этого использовать тот же Kestrel + YARP, работает отлично.
low-code платформа на PHP...
в то время, как сам PHP по своей сути и создавался как low-code для веб :)
Вот какие задачи мы решали с помощью SignalR без написания каких-то библиотек, с минимум кода:
Таймер времени на сессию пользователя, который ведётся на сервере. В одном проекте у каждого пользователя есть KPI, который считает сколько он работы проделал за время сессии, и ещё этапы работы автоматически закрываются по периодам, либо по количеству работы, и открываются новые. Всё делается автоматически в контексте сессии пользователя.
Запуск длительных обработок, например, построение отчёта. Пользователь запускает операцию, и потом продолжает работать в системе, при этом пользователю отображается прогресс(ы) запущенных операций во время его работы в системе. По завершению любой запущенной операции он может вернуться к ней и посмотреть результат или пошарить другим юзерам.
Похоже на ваши потребности?
Вы зря так реагируете.
В Hosted Services есть всё, что нужно. Это фоновый процесс, который может запускать и останавливать задачи, по одному на каждую сессию. Для коммуникации с фоновым процессом можно использовать простейший диспетчер, например, Task Channels, что также идёт из коробки.
SignalR напрямую решает задачу поддержания активной серверной сессии для каждого клиента, так как это требуется для двух-сторонней коммуникации и обмена данными.
Итого, вы не потрудились провести даже минимальное исследование платформы. Это даже не какие-то "левые" библиотеки, это всё идёт в коробке. Но написали очень много кода.
Зачем? :) Ну возможно в этом и есть смысл, возможно действительно что-то из представленного не решает тех проблем, с которыми столкнулись именно вы. Но какие это проблемы?
Разработка ПО это прежде всего инженерная дисциплина. Писать много кода -- это не значит хорошо, чем меньше кода мы пишем для достижения желаемого, тем эффективней наш труд, тем выше его ценность.
Какого-то анализа правда не хватает. Зачем писать свой велосипед на каждый чих? Потому что могу? :)
Я не пытаюсь обесценить ваши труды. Но всё же, какого-то хоть минимального исследования проблемы и существующих решений очень сильно не хватает для полноценной статьи.
Иначе выглядит это так:
-- Смотрите, какой я написал свой логгер / парсер / запускатель задач / etc..
-- А вы в курсе, что уже есть как минимум решения X, Y, Z... решающих ваши задачи?
-- А зачем? Чукча не читатель, чукча писатель
:)
Глубоко в детали пока не углублялся, но вот чего я не нашёл в содержании, это какого-то исследование альтернатив, или инструментов, которые можно было бы использовать для достижения той же цели. И, самое главное, чем данное конкретное решение лучше.
На поверхности сразу: SignalR, сессия итак создаётся на каждое подключение и держится до его окончания, разные вкладки можно объединять в группы (например, по user-id) и поддерживать процессы для группы. Чем не подходит обычный IHostedService в связке с SignalR и удержание сессионного CancellationTokenSource?
Если говорить про масштабирование вычислений, а это нам точно понадобится, то почему не Orleans? Как-то грустно, когда бекенд, который хостит апишечеку, должен ещё чего-то в фоне делать, да ещё и с лютейшими ограничениями на прилипание пользователя к конкретному экземпляру.
В общем, вопросов много, ответов мало. Если это просто ради опыта, то опыт безусловно это хорошо, но настоящий инженер перед тем, как изобрести колесо, сначала изучит другие колёса.
С рефлексией, без кеша, код пока больше подходит как учебный для объяснения. Но хотелось бы увидеть решение вообще без рефлексии, кодо-генерация.
Тут просто нет никаких причин что-то на стороне BFF в принципе хранить.
Осталось начать прыгать под кричалки. Действуйте!
Мне кажется, вы с одной темы резко перескакиваете на другую. Ваша оценка деятельности и власти России субъективна, много людей во всём мире придерживаются иной точки зрения, диаметрально противоположной вашей. Да у вас есть право на собственное мнение и множество людей также придерживаются позиции, которую декларируете вы. Много, но не все, и даже не большинство.
Поэтому, это не истина в последней инстанции, и делать какие-то выводы из такой позиции абсолютно некорректно. Дискуссия в таком случае бессмысленна и приводит только к политическому срачу.
Мы говорим о фактах. А факты состоят в том, что не Россия уходит. Её выгоняют, исключают, отключают. Что это может значить для других стран? Очевидные риски. Не будем говорить кто виноват и почему. Важен сам факт.
Оба утверждения не верные. Mapster умеет генерировать код мапперов, работает оно точно также, как и написанный код вручную. Сокращает ли количество рутинного кода? Да. Тут больше ориентируются на принятые в проекте подходы, убеждения лида, и особенности маппинга. Если они по большей части сложные и кастомные, толку не будет. Если они в основном рутинные, перекладывание значений из полей, то профит есть и не малый, если DTO много.
Вы ещё спросите, а что там с Windows, который тоже как бы ушёл :)
Ну хорошо, кажется я понял о чём вы говорите. Предоставленный токен может иметь более широкую область действия, чем авторизация в одном конкретном бекенде.
Почему бы просто не зашифровать пару access/refresh и положить в HttpOnly? В таком виде токены нельзя будет использовать на других бекендах, а только в конкретном.
На всякий случай, принцип обсуждаемого механизма авторизации в том, что токен выдаётся клиенту. Он предназначен для клиента, как удостоверение, с которым клиент может посещать различные, доступные ему заведения. Вместо решения задачи защиты токена, получается, мы полностью меняем принцип. Поправьте меня, если я не прав.
Вы как-то не ответили на вопрос, в куках будет хранится не токен, а другой идентификатор, что это меняет?