Один из возможных подходов к построению микросервисных приложений состоит в организации общения сервисов между собой посредством шины сообщений. Такая архитектура называется “Event-driven architecture”. Её преймущество в слабой связности компонентов. В этой небольшой статье я делюсь методом добавления интеграции с шиной на основе RabbitMQ в приложение, написанное на Flask.

Read more

В предыдущем посте я писал о выборе API шлюза и как KrakenD позволил нам склеивать ответы от различных API. В итоге мы отказались от KrakenD в пользу OpenResty и я расскажу почему.

Read more

KrakenD is exciting. Among all different features there’s one tech that’s particularly interesting and helpful. It’s possible to define an endpoint that calls several underlying services (either sequentially or concurrently) and merges the responses.

When it’s sequential calling, it even lets you use the data returned from the previous calls in the following. However, at the moment of writing (KrakenD 2.0.5) it’s limited to using JSON field values as parts of the request path only. You cannot compose bodies of following requests using this data declaratively.

Read more

Recently we’ve started working on an experimental internal project based on microservices principles. We’ve broken down our application into contexts using several event storming sessions, defined events, commands and aggregates. When it all took shape, we sat and started working on services.

Two months into development I went talking to the frontend team only to find that they would be more than happy to see a single entry point into API.

Read more