KY
для старта работ этого достаточно на входе, можно углубляться в приложение в процессе сколько угодно накручивая логику и всё остальное
Size: a a a
2020 November 12
СФ
Чем тогда апи сет отличается от транзакции в нашем понимании транзакции как бизнес процесса?
KY
отсутствием уровня абстракции бизнес процессов и отсутствием необходимости реализации транзакций в скриптах для удобного представления бизнесу
KY
а проблемы интерпретации могут быть такие:
1. есть бизнес процесс выгрузка отчета, сначала система его генерит у себя а потом какой то шедуль ходит и перекладывает его в "другое место". когда он появляется в "другом месте" - это конец бизнес операции. чтобы правильно её интерпретировать - ты будешь вынужден сделать чекер на стороне "другого места" на наличие этого файла потом как то подвязать его с транзакцией старта этой бизнес операции в твоем скрипте и тд. по факту ты тестируешь не систему а кусок работы шедуля.
2. в бизнес операциях часто бывают несостыковки, а включает ли она в себя вот это действие, она отображает максимально короткий поцесс получения результата или типичный? и тд. юзеры чаще всего не ходят по кратчайшему пути до своего результата, например покупку в интернет магазине, можно совершить нажав кнопку "купить в один клик" и потом ввести данные, а можно искать товар, смотреть отзывы, добавлять купоны, выбирать локацию самовывоза, платеж может не пройти и потом только купить. а бизнес операция будет покупка товара, тоже утрированно, но вроде наглядно.
@Ganeles
1. есть бизнес процесс выгрузка отчета, сначала система его генерит у себя а потом какой то шедуль ходит и перекладывает его в "другое место". когда он появляется в "другом месте" - это конец бизнес операции. чтобы правильно её интерпретировать - ты будешь вынужден сделать чекер на стороне "другого места" на наличие этого файла потом как то подвязать его с транзакцией старта этой бизнес операции в твоем скрипте и тд. по факту ты тестируешь не систему а кусок работы шедуля.
2. в бизнес операциях часто бывают несостыковки, а включает ли она в себя вот это действие, она отображает максимально короткий поцесс получения результата или типичный? и тд. юзеры чаще всего не ходят по кратчайшему пути до своего результата, например покупку в интернет магазине, можно совершить нажав кнопку "купить в один клик" и потом ввести данные, а можно искать товар, смотреть отзывы, добавлять купоны, выбирать локацию самовывоза, платеж может не пройти и потом только купить. а бизнес операция будет покупка товара, тоже утрированно, но вроде наглядно.
@Ganeles
уровень абстракции накладывает проблемы, например такие
KY
когда поднимаешь уровень абстракции до бизнес операции, у тебя появляются проблемы её интерпретации. или выявления узкого места, ведь узким местом может быть конкретный запрос, а у тебя проблемная вся бизнес операция.
у меня не всё вместе = один бизнес процесс, у меня нет привязки к бизнесу, я могу не знать что я, условно, нагружаю, мне просто дали апи, статистику с прома и валидные тела -> грузи. я утрирую, конечно, но для понимания думаю пойдет.
у меня на входе может быть набор апишек с разными интенсивностями, которые могут с друг другом соотноситься как-то например "покупка", после "добавления в корзину", а могут и не соотноситься. стремлюсь размещать их в одном треде, выставлять каждому свою интенсивность относительно максимума и стреляю, тут сразу видно какая конкретно операция имеет проблемы или какой конкретно запрос - а бизнес уж сам поймет на какие бизнес операции оно влияет и насколько это плохо. :)
у меня не всё вместе = один бизнес процесс, у меня нет привязки к бизнесу, я могу не знать что я, условно, нагружаю, мне просто дали апи, статистику с прома и валидные тела -> грузи. я утрирую, конечно, но для понимания думаю пойдет.
у меня на входе может быть набор апишек с разными интенсивностями, которые могут с друг другом соотноситься как-то например "покупка", после "добавления в корзину", а могут и не соотноситься. стремлюсь размещать их в одном треде, выставлять каждому свою интенсивность относительно максимума и стреляю, тут сразу видно какая конкретно операция имеет проблемы или какой конкретно запрос - а бизнес уж сам поймет на какие бизнес операции оно влияет и насколько это плохо. :)
или вот
KY
ну ты наверное читал
СФ
Ну про предоставление бизнесу я согласен) в моем понимании идеальная интеграция в процессы нт отдела когда он просто говорит: «асе ок» или же «все плохо и вот так нам это нужно исправлять»))
СФ
ну ты наверное читал
Ну лично для меня транзакция это не абстракция а исключительно кумулятивная штука для статистики по связанным операциям
KY
ну в моем случае так и получается по сути)) я не пользуюсь понятиями бизнес процессы и не пилю транзакции, но когда запрос плохо работает просто об этом пишу/говорю или ищу проблему или отдаю на серч кому-то
KY
Ну лично для меня транзакция это не абстракция а исключительно кумулятивная штука для статистики по связанным операциям
такую стату для особой необходимости я считаю постфактум, чтобы не перегружать этим скрипт, особенно, когда эти операции в моем скрипте ничего не связывает. допустим в отчете можно указать такая вот бизнес операция вот такая была-стала. учитывая что отчетики сами формируются, один раз запилил и забыл
СФ
Просто мне кажется не стоит пренебрегать связанными запросами, так как иногда предыдущие запросы влияют на последующие как они влияют в случае реального использования пользователем системы
СФ
А если ты этот апи дёрнешь в другой последовательности то там может создаться совсем другая картина
СФ
Грубо говоря вот есть 3 вызова api, и последовательно они работает не так как если бы ты их вызвал в разных частях скрипта
KY
тыж дергаешь в многопотоков) там нет последовательности. офкорс, если последовательности требует логика я её соблюдаю. грубо говоря, есть реально связанные вещи - без связи их не выполнить нормально, а если условно связные вещи ("некий бизнес процесс": логин, переход на главную, два тыка, выход). в случае с первыми - всё ясно, а вот вторые я не вижу смысла пилить последовательно - загоняем себя в рамки. последовательность и реальная связность для меня не важный вопрос. вопрос скорее в чистоте скрипта от нагромождения обёрток в виде транзакций + вопрос в удобстве интерпретации: в транзакциях какой-то пользовательский сценарий 1 работает медленно, а почему и что за сценарий - тебе предстоит вспомнить, проверить и тд. в моем случае у меня работает медленно конкретная операция, доп действия не нужны. логика такая)
KY
безусловно, я юзаю транзакции в каких то случаях. когда асинхронщина, например
СФ
Ненене
СФ
Много потоков это понятно, но если ты выполняешь запросы в рамках одной сессии клиента, допустим, то в той же бд будут добавляться/мутироваться данные именно для клиента
СФ
Например: клиент запросил тяжёлую генерацию отчета и потом сразу переходит к просмотру
СФ
В реальной жизни
СФ
А если ты пихнешь два этих запроса в разные части скрипта, то в твоём скрипте вторй запрос выполнится значительно быстрее чем при реальном юзкейсе