Ruby meetup едва успел закончиться, а мы спешим поделиться с вами его докладами в студийной записи. Потому что полезные видео стоит добавить с закладки сразу. В этот раз мы обсуждали асинхронность с точки зрения очередей и событий, а также спорили, можно ли считать снапшот тесты общим провалом.
Межсервисное взаимодействие. Очереди сообщений
Никита Богомолов, backend developer Evrone
Взаимодействие через очереди — это современный подход в коммуникации микросервисов, который расширяет возможности написания кода и позволяет гибко настраивать отправку и получение данных. Так как в докладе представлены базовые знания, эта информация поможет сделать «быстрый старт» в использовании очередей и понять, нужно ли вашей системе асинхронное взаимодействие.
Почему это важно: это современный подход наряду с использованием микросервисов. Отсутствие брокера в приложении на старте может стать серьезной архитектурной проблемой в будущем.
Кому полезно: тем, кто не работал с очередями, и для тех, у кого нет понимания, какие плюсы можно получить от использования асинхронного взаимодействия.
Как начать использовать событийную модель в сервисах, и не свалиться в распределенный монолит
Антон Давыдов, консультант Solution Architect
В своей практике часто вижу, как реализация нового сервиса с асинхронными коммуникациями или перенос синхронных коммуникаций на асинхронные сваливается в долгострой, который приводит к распределенному монолиту или проблемам, связанным со сложностью поддержки асинхронных систем. В докладе расскажу об асинхронных коммуникациях. Покажу как найти события, почему события должны быть разных видов, как добиться эволюционности, и что делать дальше.
Почему это важно: в практике встречаю проблемы связанные с асинхронными событиями, которые приводят к усложнению поддержки систем.
Кому полезно: всем, кто использует события и тем, кто свалился в распределенный монолит, и не знает что делать.
Snapshot testing
Андрей Молчанов, tech lead
В пирамиде Фаулера снапшот тестирование занимает самую верхнюю позицию. Это значит оно медленное и дорогое. Но это не означает что Full-stack разработчики должны его пропускать. Обычно находят некую середину, покрывают только критически важные бизнес-процессы: регистрацию, оплату и т.д. В докладе посмотрим, как ещё можно оптимизировать процесс.
Почему это важно: развитие комьюнити напрямую зависит от самих разработчиков. В докладе я покажу, на что можно обратить внимание open source энтузиастов.
Кому полезно: Full-stack разработчикам и людям ищущим идеи для развития open source.