Всегда интересовало, зачем вы тестите save(entity), get(энтити)
Там же черная спринговая магия под капотом, иногда, зависящая от неочевидных конфигов. В этом случае, полезно лайтово проверить работу энтити, чтобы убедиться, что конфиги не отъехали.
Если исключить вариант, что забыли про конфликт, то релиз катится в три (или больше) шага.
1) промежуточная версия — чтобы писать not null в бд
2) заполняем в бд старые данные с null
3) катим релиз с not null
api чужого сервиса мокают на этапе разработки своего сервиса.
типа:
1) что-то поделали в нашем сервисе.
2) позвали чужой сервис
3) получили результат
4) дальше стали что-то делать в нашем сервисе.
вот на этом этапе удобно не зависеть от чужого сервиса, а обложиться моками.
и это не отменяет полезность интеграционных тестов
А-а, ну да, забираю свои слова обратно.
Действительно, Роскомсвобода и Ко написала письмо Байдену, в частности:
Access to the internet is essential to the protection of freedom of expression, access to information, and free association, and is increasingly recognized as a human right. Journalism and independent media depend on access to secure and reliable information technologies to document events inside contested areas, and to enable people to bypass state controls on information. Overly broad restrictions on the access of the Russian people to the internet would further isolate the embattled pro-democracy and anti-war activists, and impede the ability of NGOs, human rights groups, journalists, and attorneys inside and outside Russia to provide critical information to citizens about the current state of affairs and their rights.
После этого Байдену стало очевидно, что немного перегнул с санкциями, в ущерб свободам и демократическим ценностям. И отменил.
когда стало понятно, что Huawei и Ко в течении короткого времени заместят все то что нажито Cisco и Ко непосильным трудом за многие годы, можно немного про санкции и забыть.
Расскажите, пожалуйста, зачем на стороне пользовательского приложения (в нем сидит человек) заводить историю с refresh- и access-токенами, затем создавать на всех запросах отдельную логику на 401 ошибку от сервера, конечно, при условии что auth-сервис и прочие сервисы, действительно наши.
Когда auth-сервис не наш, но мы ему доверяем, там понятно, для чего приседания с refresh- и access-токенами.
В этом случае, если Боб или Алиса точно хотят убедиться, что данная электронная подпись действительно принадлежат контрактанту — ему достаточно валидировать приватные данные друг друга в децентрализованном хранилище и дальше спокойно вести дела друг с другом. Никакие централизованные органы для этого не нужны. И подписывать этой подписью можно что угодно, когда угодно, сколько угодно раз.
Ничего не понятно.
Вот есть я, и есть некий контрагент, где-то там далеко.
Нам нужно подписаться под документом, при этом я должен быть уверен, что данный контрагент уполномочен на подписание таких документов.
Что я должен увидеть в блокчейне, что меня сразу успокоит, и я буду уверен в легитимности подписания?
В случае обычной электронной подписи я вижу сертификат, в нем атрибуты юрлица, физлица, кто и когда выдал сертификат, и прочее, что я могу использовать для проверки в реальном мире. А что я увижу в блокчейне, и почему я должен этому доверять?
Но ведь бд, пусть посередине есть обертки, является синхронным объектом. Даже если эти обертки дают псевдоасинхронность. Псевдо, потому что традиционная бд синхронна.
А если вспомнить, что у любой БД ресурсы ограничены, и количество сессий к БД тоже ограничено, то получаем что с одной стороны можно под нереактивное взаимодействие с БД выделить отдельный блокирующий пул потоков, равный количеству сессий к БД, и пользоваться реактивностью, и нереактивностью, когда это нужно. А с другой - реактивное взаимодействие, но с разными ограничениями, типа невозможности использовать уже существующий инструмент ничего не знающий про реактивность.
Я к тому, что совершенно не обязательно съезжать полностью с традиционного jdbc, и героически побеждать клубок проблем, вызванных переходом на r2dbc.
Стоит добавить, что GraphQL хорош для взаимодействия человеческого фронт и бека.
Для взаимодействия бековых сервисов между собой уже не так хорош.
На поставщиках данных. Где они и должны быть, канонически
Это для mutation, но с mutation итак много нюансов.
Там же
чернаяспринговая магия под капотом, иногда, зависящая от неочевидных конфигов. В этом случае, полезно лайтово проверить работу энтити, чтобы убедиться, что конфиги не отъехали.1) промежуточная версия — чтобы писать not null в бд
2) заполняем в бд старые данные с null
3) катим релиз с not null
типа:
1) что-то поделали в нашем сервисе.
2) позвали чужой сервис
3) получили результат
4) дальше стали что-то делать в нашем сервисе.
вот на этом этапе удобно не зависеть от чужого сервиса, а обложиться моками.
и это не отменяет полезность интеграционных тестов
Понятно же, что Hello world в любой области нужно начинать с простых базовых вещей.
По мере набора мышц, будет и усложнение.
1) подделка настоящих документов, удостоверяющих личность
2) подделка цифровой личности через deepfake
и там, и там цель — получить доступ к счету в банке.
и там, и там — преследуется по закону
Mail.ru походу тоже уже прикрыл бесплатную почту для домена
Это общемировые рекомендации повторенные много раз.
Например
Для русского — можно не следовать, т.к. выигрыша между Добавить и Добавлено почти нет
Действительно, Роскомсвобода и Ко написала письмо Байдену, в частности:
После этого Байдену стало очевидно, что немного перегнул с санкциями, в ущерб свободам и демократическим ценностям. И отменил.
Вот что значит настоящая демократия.
А какая должна быть политика, чтобы она не была психологическим насилием над нормальным человеком? пример
когда стало понятно, что Huawei и Ко в течении короткого времени заместят все то что нажито Cisco и Ко непосильным трудом за многие годы, можно немного про санкции и забыть.
Когда auth-сервис не наш, но мы ему доверяем, там понятно, для чего приседания с refresh- и access-токенами.
но можно и абстрагировать. payment шлет изменения и дальше его ничего не волнует (fire-and-forget). а отдельный ответственный кладет изменения в кеш.
Ничего не понятно.
Вот есть я, и есть некий контрагент, где-то там далеко.
Нам нужно подписаться под документом, при этом я должен быть уверен, что данный контрагент уполномочен на подписание таких документов.
Что я должен увидеть в блокчейне, что меня сразу успокоит, и я буду уверен в легитимности подписания?
В случае обычной электронной подписи я вижу сертификат, в нем атрибуты юрлица, физлица, кто и когда выдал сертификат, и прочее, что я могу использовать для проверки в реальном мире. А что я увижу в блокчейне, и почему я должен этому доверять?
можете привести пример такой рекомендации? просто стало интересно где так рекомендуют
Но ведь бд, пусть посередине есть обертки, является синхронным объектом. Даже если эти обертки дают псевдоасинхронность. Псевдо, потому что традиционная бд синхронна.
А если вспомнить, что у любой БД ресурсы ограничены, и количество сессий к БД тоже ограничено, то получаем что с одной стороны можно под нереактивное взаимодействие с БД выделить отдельный блокирующий пул потоков, равный количеству сессий к БД, и пользоваться реактивностью, и нереактивностью, когда это нужно. А с другой - реактивное взаимодействие, но с разными ограничениями, типа невозможности использовать уже существующий инструмент ничего не знающий про реактивность.
Я к тому, что совершенно не обязательно съезжать полностью с традиционного jdbc, и героически побеждать клубок проблем, вызванных переходом на r2dbc.