Я обожаю диаграммы. Рисовать их на доске или на бумажке и одновременно обсуждать с программистами. Это мой способ разобраться самому и объяснить что-то сложное другим.
На видео — реальные схемы разработки нового проекта для igooods. В статье — обзор классных инструментов и примеры из жизни.
Segment — очень классный сервис, который собирает данные аналитики и раскидывает по десятку доступных интеграций, которые вы выберете. Этакий мультиплексер аналитических данных.
Они рассказывают, как уткнулись в проблемы производительности, выделили отдельные задачи в микросервисы и стало лучше. В течении года число похожих друг-на-друга микросервисов выросло до 140(!) и начались серьезные проблемы менеджмента зависимостей и деплоя. Тогда они собрали все сервисы обратно в один четкий монолит и опять задышали свободно.
Отличный пример, который показывает, что каждому инструменту (и подходу) — своё время и место. Включайте мозги, не идите на поводу у хайпа.
Программисты любят приводить аналогию строительных блоков. Мол «соберём из готового». По моему опыту - обычно, «блоки» мало похожи на Лего и гораздо больше - на этот вот прекрасный конструктор :)
Хорошая полемическая статья (aka trolling) на на тему «чем плох REST».
1. Переводить сложные операции на язык, в котором всего 4 глагола - то ещё развлечение.
2. В парадигме REST неестественно передавать изменения машины состояний, а это часто необходимо и ошибки на этом фронте могут быть фатальны.
3. Коммуникация ошибок и других особых состояний: «всегда HTTP 200 OK, а ошибка в теле» или придумаем свои коды?
https://medium.com/@pakaldebonchamp/rest-is-the-new-soap-97ff6c09896d
Мой вывод: парадигмы, правила и концепции - это наши рабочие инструменты. Не человек и дела для инструментов, но наоборот. Каждой задаче - свой инструмент. Черт, кажется это просится в инстаграм глубокомысленные цитаты. Сорян.
Рассказываем, как устроены подкасты в Медузе https://dev.meduza.io/eff4c68d24f2
Составляем карту технологических зависимостей Медузы.
Это схема того, где искать поломку, если что-то вдруг идет не так. Продуктов и сервисов становится так много, что в скоро связи между ними перестанут помещаться в голову без препаратов.
Посередине слева — полный список «пользовательских view»: то, откуда можно читать Медузу. Web, iOS, Android, Instant Articles, etc. 20 пунктов.
Ряд сверху — список зависимостей для каждого View. Зависимости есть от внутренних сервисов и от внешних.
Завтра будем составлять список зависимостей для внутренних сервисов — там уже будут базы данных, серверы и прочие низкоуровневые элементы.
Где лучше составлять такие схемы? Я пока остановился на Scapple. Кстати, эта же компания уже много лет производит очень мощную программу для писателей Scrivener — ведь не всем писателям нравится WordStar.
Извините, что не хайрез. Смысл, надеюсь, понятен.
У строителей под моим окном классическая «микросервисная архитектура приложения». У них есть 3 сервиса — полый бур, сверлящий дырку в земле, бетономешалка, не дающая бетону застыть и насос, закачивающий бетон из мешалки в отверстие, сверлимое буром.
Красным на картинке отмечены места, в которых один сервис «передает» бетон другому. Там должны быть подходящие отверстия, крепления и допустимое предельное давление бетона (чтобы это всё не разорвало) — это API. API — договоренности, по которым сервисы общаются друг с другом.
Допустим, можно было бы сделать убер-машину, которая умеет все — сверлить, качать и мешать. Засыпаете бетон, вставляете сверла и она делает вам готовые заполненные бетоном дырки — это была бы «монолитная архитектура приложений». Её было бы сложнее транспортировать по улицам и, наверное, ей нужен был бы очень крутой инженер для обслуживания.
В случае разделения машины на части мы можем выбрать разных производителей отдельных частей, достаточно, чтобы все они соблюдали стандарты и поэтому могли работать вместе.
Изменение архитектуры проекта при масштабировании. Обратите внимание на отличающуюся конфигурацию палок и брёвен.
