Комментарии 10
А можете рассказать почему понадобилось выбрать именно кракен, а не nginx/ingress или другую попсу?
Если правильно понял вопрос, то ответ простой - набор функций, которые предоставляют API Gateway решения. Если сравнивать с Nginx open source, то там просто нет всех тех функций, которые есть у API Gateway. Тот же Kong - это же как раз надстройка над nginx, чтобы добавить в него те функции, которых в Nginx нет. Другое дело, что есть Nginx Plus, в котором есть уже полноценный API Gateway, но это платное решение с закрытом исходным кодом. Надеюсь ответил на вопрос.
Интересная статья, спасибо!
Можете, пожалуйста, рассказать как решали проблему повторения настроек в конфиге (и вообще его разрастания)?
Например, если нужно для каждого эндпоинта сделать jwt верификацию, то мы постоянно дублируем какую-то часть конфига. Используете ли text/template, который поддержиает krakend?
Да, конфиг быстро разрастается, особенно если для каждого endpoint'а нужно одни и те же плагины подключать, одни и те же заголовки указывать и т.д. Мы используем как раз возможности шаблонизации, которые вы как раз упомянули https://www.krakend.io/docs/configuration/flexible-config/. Сейчас у нас 3 среды, где крутится кракен и конфигурация очень похоже для них, поэтому в шаблон вынесли всю общую часть. В планах еще шаблонитизировать описание самих endpoint'ов. Потому что там уже начинает сильно дублироваться пробрасываемые заголовки, параметры формата ответа и подключаемые плагины.
в ближайшее время мы планируем написать как минимум еще один плагин, для объединения OpenAPI спецификаций backends.
Это очень полезно было бы. Из подобного самое популярное решение, судя по всему: https://github.com/HamzaOralK/openapi2krakend А так, только в Interprise версии.
Планируете опубликовать свой плагин?
Планируете ли публиковать ваши наработки в открытом доступе?
Как раз появилась нужда в написании плагина, спасибо за понятное объяснение.
Выпускайте Кракена: опыт использования KrakenD