Это третья статья из цикла «Проектирование GraphQL API».

В предыдущих статьях мы рассмотрели основы GraphQL и принципы проектирования схемы. Теперь перейдем к архитектуре — фундаменту, определяющему, как GraphQL API будет работать в реальных условиях.

При проектировании интеграций через Kafka или другие брокеры сообщений можно столкнуться с проблемой зависимых сообщений в разных очередях/топиках.

Давайте изучим эту проблему подробнее и проанализируем, как ее можно решить с помощью паттернов проектирования Dead Letter и Inbox.

Расскажу про системы с микросервисной архитектурой (MSA). Как они устроены, как я их анализировала, какие увидела проблемы и преимущества.

Статья не раскрывает лучшие практики использования микросервисов и не разоблачает их излишнюю популярность. Основная цель - описать технологию и процесс работы с ней с точки зрения системного аналитика.

Пост о том, зачем и как аккуратно вести проектную документацию, даже если у вас Agile. Делюсь перечнем и структурой полезных документов и рекомендациями по работе с ними.

Речь пойдет в основном о внутренних документах, которые обычно никто не просит писать, но которые на самом деле нужны команде.

1. Зачем нам что-то делать? (нужно больше золота)
2. Что мы будем делать? (все как у людей, но дешевле)
3. Как мы это сделаем? (с блокчейном и датасаентистами, естественно)
4. Когда мы это сделаем? (вчера, а отрефакторим «потом»)