Comments 8
Дмитрий, разрешите покритиковать вашу статью.. Для меня из неё непонятно практически ничего. Всё что я отсюда понял - есть такой замечательный инструмент и он как-то вам помог что-то сделать. За деталями я пошел на офсайт и на самой первой странице документации картинка мне объяснила больше чем вся ваша статья.
Спасибо за сведения о новом инструменте, но я лично плюс статье поставить не могу. Минусы, впрочем, тоже не буду.
Дмитрий, разрешите покритиковать вашу статью (c) Для меня в принципе понятно, что у вас за инструмент, но непонятно главное - зачем он нужен? Похожая функциональность есть "из коробки" в любом облаке, будь-то AWS API Gateway или там Azure API Management. Чем ваша тулза отличается от дефолтных, чтобы был смысл добавлять ещё одно звено в тулчейн?
Ну, побродив по документации, я вижу что смысл в таком инструменте есть. Помимо того, что он помогает, частично, избавиться от фатального недостатка встроенных в облако сервисов, он еще и расширяем с помощью самописных плагинов. Есть интеграция с брокерами через AMQP, например, что тоже интересно. Их неуклюжее объяснение Backend-For-Frontend принципа мне не нравится, но, тем не менее, многие встроенные фичи довольно интересные.
Однако, к статье именно что вопросы - как он применяется и чем именно он выигрывает относительно чего-либо другого. В данный момент в статье больше описаны какие-то малоинтересные детали деплоя.
Хоть я и не Дмитрий, а иной чувак, отвечающий за инфраструктуру в другом стартапе, но могу рассказать на примере GCP. В GCP эту задачу решают аж три продукта: Apigee, Managed API Gateway и Managed Endpoints.
Предположим, мы хотим решать задачу монетизации API. То есть, чтобы не растаскивать специфическую логику по бекендам, API Gateway должен:
1) аутентифицировать пользователей, ходя в некоторую auth db с кешированием у себя
2) проверять статус оплаты -- некоторую метаинфу, взятую из биллинга
3) в зависимости от статуса -- возвращать на запросы ошибку или устраивать rate limiting (что тоже сводится к возврату ошибки в какой-то момент, вместо передачи запроса бекенду)
4) отправлять в биллинг статистику потребления в разбивке по пользователям в реальном времени
Apigee -- типичный кровавый энтерпрайз с развесистыми XML-конфигами и конскими ценами, купленный Google в 2015.
Он умеет делать перечисленное, но стоить это будет в минимальной конфирурации $30к в год (и оплата на год вперёд, договор и всё такое -- для стартапа прямо мечта) и всё равно придётся многое дописывать и допиливать. Да и не очень-то cloud-native решение, как ни странно -- IaaS для конфигурации всего это дело представлен почти незадокументированным плагином. Ни о чём вроде terraform провайдер мечтать не приходится.
Managed API Gateway -- чрезмерно минималистичный продукт, который только по сути маршрутизацию запросов по разным бекендам умеет делать и очень кривую аутентификацию на статичных API-ключах. Никаких возможностей интеграции с биллином и условной логики нет. Ах да, ещё конфигурируется это всё исключительно на Swagger 2, про OpenAPI 3 они не слышали и внедрять не планируют.
Managed Endpoints -- похожая сущность на Managed API Gateway, разве что в основе взят Extensible Service Proxy v2 -- сборка Envoy, конфигурируемая через GCP-сервис управления конфигами.
В общем, так я и не смог решить встроенными GCP инструментами описанную задачу.
Поэтому пришлось отправиться в OpenSource и external SaaS миры, где, увы, в этом месте всё тоже оставляет желать лучшего -- прямо чтобы парой кликов заработал интегрированный с API Gateway портал API разработчика, где можно привязать карту для оплаты и смотреть отчёты биллинга -- с этим 3.5 компании пытаются что-то делать и скорее в зачаточном состоянии.
Было бы интересно сравнение, например, с Spring Cloud Gateway.
KrakenD — новый друг для вашего backend