Посмотрел ваш короткий ролик по микросервисам. Там комменты отключены, поэтому пишу тут. За 2 минуты объяснили отличие от монолита лучше, чем многие другие за более долгий срок)
Так классно не знать тему. Но уже знать программирование. Открываешь новый урок, как этот, допустим. Случаешь. Все составляющие и вся терминология уже известны. Просто все интуитивно понимаешь. Еще не знаешь как реализовать, но точно понятно что это возможно. Очень довольный закрываешь урок, понимая, что теперь Я могу )))
Вопрос к рисункам. Кажется, схемы перепутаны. Когда происходит синхронный запрос, то с точки зрения процесса мы находимся в нем же и ожидаем, мы не можем завершить процесс или начать новый это как раз с точки зрения UML правая картинка. А вот когда асинхронный запрос, то мы можем делать другие действия это означает что при отправке запроса наш процесс завершается (условно, там приходит 200 ОК/ 201 и проч), запрос зарегистрирован). И при получении ответа возникает новый процесс его обработки. В общем, схемы нарисованы Про коды тоже можно дискутировать, какой именно стоит отправить, но учитывая, что у нас есть notification endpoint, то самое правильное это либо 201 (что канонично), либо 200 ОК. Потому что нам надо передать какой-то id ресурса, где мы можем спрашивать статус. Для 2 минут было хорошо!
Согласна с вашей логикой по рисункам, можно так смотреть на процесс. Но на практике и в других учебных материалах, встречала именно ту версию, которую изложила. Поэтому она кажется мне привычной и общепринятой. По кодам ошибок - возможно. На практике, к сожалению, не встречала, чтобы 201 возвращали. Но, возможно, это было бы более корректно. Буду иметь в виду, спасибо!
Великолепное объяснение, спасибо за труд
Помогло уложить в голове самую суть
Очень ждем новых видео! :)
Спасибо за видео!
Посмотрел ваш короткий ролик по микросервисам. Там комменты отключены, поэтому пишу тут. За 2 минуты объяснили отличие от монолита лучше, чем многие другие за более долгий срок)
Просто 5 баллов из 5. Коротко, емко и понятно.
Спасибо :)
Ксения большое спасибо вам за видео! Ждем новых видео на вашем канале;)
спасибо за емкость и краткость
Большое спасибо за четкое объяснение!
Спасибо за лаконичную, чёткую подачу.
Это лучшее объяснение ! Спасибо
Коротко и очень понятно! Спасибо!
Очень круто, и очень быстро! Спасибо. Подтвердили мои догадки :)
Спасибо огромное! Ксения вы молодец, будьте здоровы и счастливы) Лойс + подписка + колокол!
Большущая благодарность!!! :)
Еще хотелось бы узнать отличия rest и soap :)
Большое спасибо! Мега полезно и супер коротко, это гениально!
Так классно не знать тему.
Но уже знать программирование.
Открываешь новый урок, как этот, допустим.
Случаешь.
Все составляющие и вся терминология уже известны.
Просто все интуитивно понимаешь.
Еще не знаешь как реализовать, но точно понятно что это возможно.
Очень довольный закрываешь урок, понимая, что теперь Я могу )))
Спасибо: ясно и лаконично!
Я нашел как в сиквенс диаграмме показать асинхронность ..спасибо
Спасибо!
присоединяюсь к остальным комментаторам: хорошее объяснение. только опустили что такое десижн. полагаю, обратный адрес клиента
Отлично!
Очень классно объяснили, спасибо большое!
Информация крутая и подача тоже. Только вот микрофон подводит :(
На примерах Сервис1 и Сервис2. А в качестве сервиса1 может быть обычный клиент? и какой адрес тогда шлётся в коллбэке?
Вопрос к рисункам. Кажется, схемы перепутаны. Когда происходит синхронный запрос, то с точки зрения процесса мы находимся в нем же и ожидаем, мы не можем завершить процесс или начать новый это как раз с точки зрения UML правая картинка. А вот когда асинхронный запрос, то мы можем делать другие действия это означает что при отправке запроса наш процесс завершается (условно, там приходит 200 ОК/ 201 и проч), запрос зарегистрирован). И при получении ответа возникает новый процесс его обработки. В общем, схемы нарисованы Про коды тоже можно дискутировать, какой именно стоит отправить, но учитывая, что у нас есть notification endpoint, то самое правильное это либо 201 (что канонично), либо 200 ОК. Потому что нам надо передать какой-то id ресурса, где мы можем спрашивать статус. Для 2 минут было хорошо!
Согласна с вашей логикой по рисункам, можно так смотреть на процесс. Но на практике и в других учебных материалах, встречала именно ту версию, которую изложила. Поэтому она кажется мне привычной и общепринятой.
По кодам ошибок - возможно. На практике, к сожалению, не встречала, чтобы 201 возвращали. Но, возможно, это было бы более корректно. Буду иметь в виду, спасибо!
@@AitiExpress А вы можете подсказать учебные материалы, где таким образом отображаются синхрон и асинхрон?
Здравствуйте, спасибо за видео. На видео не указано, как называется второй способ
Здравствуйте! Сама только недавно узнала название: Short polling
Есть ещё третий вариант: Long polling. С удержанием открытого сокета
А определение дать не судьба,или все филтмы нудно еще догуглить