Спасибо за фидбек! Тут автор дал общую информацию по интеграции - не думаю, что её можно рассматривать как исчерпывающую по интеграции микросервисов - это факт. Думаю, начинающим разработчикам может быть полезно и системным аналитикам. А про хореографию, оркестратор и SAGA, кстати, видео тоже планируется.

Как минимум разрабам не по стэку. Например фронтам

Для менеджеров полезно, для общего понимания.

Системным аналитикам 👌

Да, автор так и говорит, что его ситуация - когда нет обратной связи для менеджера (ни синхронной, ни асинхронной). Согласен, это немного странно выглядит, но, видимо, какие-то ограничения были на проекте.

О покойниках либо хорошо либо ничего

Есть такое. Про GraphQL можно глянуть отдельное подробное видео kzfaq.info/get/bejne/jtGoaNqj1LXYZ6M.htmlsi=CnJaN2tq21jK2h56 и сравнение с другими методами интеграции kzfaq.info/get/bejne/ebGpZLGhydXUn2w.htmlsi=Gnoyhsxq_c7qL2Wn

​​@@itdev4680почему о покойниках? не приходилось работать, но в проекте предстоит, интересно почему так считаете

имхо graphql, rest, grpc и soap (с этим не работал) отличаются только количеством оверхеда, который тебе нужно добавить в код. это все надстройки над http и принципиальной разницы между ними нет

​@@N5O1 есть разница, как с ними работать, как сложно их поддерживать и составлять контракт, поддерживать обратную совместимость, и насколько хорошая у них пропускная способность. Ну и всё-таки не сказал бы, что правильно будет сказать "http - всё одна фигня" - http/2 в случае gRPC довольно существенно отличается от рестового http.

В статье специально проговариавается, что в REST нет именно обязательной схемы, в отличии от того же gRPC или SOAP. А про кэширование SOAP - на уровне самого протокола его действительно нет, но это не значит, что его нельзя реализовать на уровнях клиента, прокси, сервера приложений, БД и пр. - согласен.

Тут, думаю, слегка преувеличено про "неприспособленность REST к высоким нагрузкам". Речь больше про то, что есть определённая грань нагрузки, когда время на сериализацию/десериализацию protobuf компенсируются скоростью передачи данных. На маленьких нагрузках - действительно смысла нет - можем только ухудшить ситуацию. На больших (по конкертике есть исследования, где находится эта грань целесообразности, поищу, скину) - gRPC будет уже эффективнее. Ну и стриминг у gRPC. И жёсткий контракт.

@@ListenIT_channel Ну тут я докапывался, конечно же, к формулировке именно. Понятное дело, что на масштабах в несколько десятков тысяч RPS REST начнет проигрывать gRPC, но это ни то, чтобы супер частый кейс, когда системы сталкиваются с такими нагрузками. Там и голый gRPC вряд ли сам по себе справится - придется придумывать что-то помимо смены протокола

Для быстрого старта может и сойдёт, но в долгой перспективе мертвая идея. Pub/sub работает крайне схоже на udp и ему пофиг доставлено ли сообщение или нет.

Я работаю с редисом в качестве брокера, в целом норм, зависит от нагрузки офк, если редиса мало то смотри в строку кролика

брокера? ​@@augustsionis6542

параллельная обработка и подразумевает ответить потом

Асинхронность и параллельность это вообще разное Первое значит существование отправителя и получателя в разных временных системах. Второе это одновременное выполнение процессов, ну или псевдопараллельное чаще. Как можно выполнить отправку запроса одновременно с приемом? Тахионные сети не изобрели еще

Как правило, табличные базы данных, это узкие места любого проекта. Они потребляют относительно много ресурсов и времени на работу. Можно конечно использовать для обмена сообщениями тот же Redis, но в этом нет особого смысла так как полноценные брокеры сообщений используют более оптимизированные решения под капотом и уже имеют свой api

Почему, используется.

кажется такая архитектура есть, и его называют монолит, нет?))

если нагрузка небольшая, то можно и через таблицы в реляционной бд имитировать асинхронную очередь. Но при росте нагрузки и/или числа конкурентных пользователей быстро встанут вопросы настройки уровней изоляции транзакций, блокировок записей в этой общей таблице, что в итоге ради соблюдения ACID не даст хорошей производительности. А вот специализированные решения для асинхронных очередей сообщений используя более эффективные структуры данных (например LSM-tree вместо типичного для реляционных субд B-Tree), всякие lock-free очереди и т.п., и в целом при другом наборе требований к таким системам, дают лучшую (а и иногда предельно возможную) производительность для задач "отправки сообщений"

PS: кстати, использования имитации очередей на базе реляционных субд, дает возможность на более ранних стадиях проекта подумать о снижении связности между компонентами системы, ввести необходимые разрезы функционала по асинхронности взаимодействия, а иногда и задуматься о возможных паттернах асинхронного взаимодействия - все это пригодиться при дальнейшем росте проекта. А уже потом при необходимости доучить специфику всяких RabbitMQ и Kafka, когда нагрузка этого потребует.

РЕСТом не пользовался?

Автор попытался, видимо, раскрыть чем связать, а не как

Так все в АйТи делают чтобы демонстрировать свою шаристость

@@Jansisoev пантуются , умный человек всегда сможет доступно объяснить другому.

Сейчас разберёмся, в чём тут проблема.

@@ListenIT_channel короче моего кореша взяли, у нас было только одно отличие, он написал «фронтенд разработчик» в регистрации, а я «программист-разработчик». Если получится решить проблему и меня запишут на митап авито.тех, в губы тебя расцелую(гетеросексуальная шутка)

Получил официальный ответ от AvitoTech, вот, что ребята пишут: «К сожалению, возможности площадки физически ограничены, и она не может вместить всех-всех желающих. Все заявки мы одобряли вручную, и, если кому-то пришёл отказ, то, к сожалению, это означает, что офлайн-билетов попросту не осталось. Мы благодарны всем за интерес к нашему мероприятию! Кстати, можно будет посмотреть онлайн-трансляцию по ссылке: kzfaq.info/get/bejne/nplofthelbHGf30.html »

@@ListenIT_channel ну короче работают они так себе. Спасибо, что выяснил, они мне ответили тоже самое. Но коллегу моего, с таким же стажем и профилем - взяли, а я зарегестрировался на пару часов раньше. Слишком странно, ну да ладно. Спасибо, за уделенное тобой мне внимание)

@@ska6391 Привет! С конференцией действительно не получается уже совсем никак :( Но мы ждём вас на наших митапах и других мероприятиях!