у ExpressGateway есть плагинная система, они на Node.JS выросли из Express.JS, еще заявлена поддержка у Kong, но эту сторону не исследовал.

мы исследовали подобное раньше, ничего такого более менее целостного и пригодного под задачи свои не нашли. был ещё на ноде IBM API Connect, на жабе похожие штуки мог делать WSO2 там тоже есть подобие контрутора различных сценариев из готовых блоков/политик. в итоге используем самодельный. на го ещё какой-то был со сценариями на луа, но не помню как называется

Ну, логично, так как API Gateway без кода и без bff довольно бесполезен.
Но это тоже делают плохо )

Да достаточно просто делать http/grpc-calls на внутренние ресурсы и преобразовывать результаты.
Исполнитель пользовательских сценариев - это не про bff же обычно

а без него bff не сделать. bff всегда подразумевает некую агрегационную логику или перобразования. его можно либо писать руками и задейстсовать трудовые ресурсы кодеров, либо взять некий инструментарий, где даже аналитики смогут из кубиков и простейших скриптовых вставок эти bff собрать или нагенерировать. собственно второе сейчас и начинает становистя популярным, комплесные решения которые какбе глобально про service mesh, но там есть инструментарий чтобы клепать bff. api connect, новый wso2 итд. они все про это, обмазывай всё мешом, попутно быстро клепая bff узлы или иные фильтры и преобразовтаели потоков данных/запросов

Ну, а смысл аналитков использовать как программистов, это получается плохо и неэффективно?
Разница же, реально, только в том, что у аналитиков обычно какие-то неудобные языки типа js или lua, нет никакой нормальной работы с версионированием, выкладкой, CI/CD и вот этим всем.
При этом все равно пишется код, только там не про параллельность, ни про обработку ошибок, ни про гарантии никто не думает.

Хотя мы вот сейчас в своем собственном Gateway даем возможность просто подгружать кусочки на котлине, которые пишет внедрение или сам клиент. Но там как раз оно завязано на наш configuration manager, где есть и версии и возможность реализации CI/СD etc

1. это дешевле
2. это быстрее в плане time to market, если учитывать время аллокации команды разрабов на различные проекты. особенно если у какой-то команды нет толком разработки или есть например только фронты.
3. об ошибках и стабильности думают. телеметрия, мониторинг, деплои, ci/cd пайплайны автомасштабирование - всё идёт в к этому (мы уже запилили это по пбольшей части), что это автоматизируется в комлексных решения про меши. а вот варианту 'использовать программистов' придётся как раз это всё делать, если они заранее не заготовили никакой автоматизации хотя бы в виде sdk

код bff или промежуточных блоков меша - обычно довольно примтивен и шаблонен, его может написать в прицнипе любой человек с базовым занением скриптухи, переложить и отфильтровать какой-нибудь джейсон - это не рокет саенс. особо квалифицированных кодеров просто не нужно для таких задач, лучше если уже опытные разрабы будут какие-то более сложные блоки/политики, которые смогут потом переиспользовать в различных сценариях. так получается более эффективаня утилизация трудовых ресурсов

суммарный ответ довольно прост - это быстрее и дешевле. примерно такая суть у этой парадигмы/стиля

Многие просто переехали js => ts, так что с типами там все намного лучше.

1. это кажется дешевле, так как они просто делают гораздо меньше, чем программисты (а потом за ними куча людей подчищает).
Ну и если аналитик дешевле чем программист и занимается работой программиста - то может что-то не так с практикой найма?
2. в смысле? какая разница, кто решает задачу в общем процессе - аналитик или программист?
если для задачи не нужно ни тестирование, ни версии, ни CI/СD - то и программистам оно не нужно и будет так же быстро.

А в каком bff из коробки есть нормальная работа с конфигурациями? Ну не git же открывать для доступа из внешнего периметра..

Преобразовать json (особенно если без paging, фильтрации, обогащений и т.п.) - это да, это несложно. Особенно если без параллельных запросов.
Да, работать будет медленно, никакой рефакторинг или даже просто structured find по коду невозможен, баги плохообнаруживаемы, ну да ладно.
А вот уже при изменениях по разным сервисам (бизнес-транзакциям) все гораздо сложнее и там только bff не поможет, увы.

1. не кажется, а есть. по краней мере для наших задач, мы ритейл, у нас не так много разработки во многих командах. сравнили, оказалось дешевле
2. разница в том, что кого-то у тебя нет, кто-то занят, а кого-то надо нанимать, low code подход позволяют подходить к этмоу гибче

в нашем есть. если нужен внутренний контур, можно поставить внутренний гитлаб. не вижу здесь каких-то проблем

работает со скоростью микрсосервисов на ноде, т.е. приемлимо, с парарельностью тоже всё в порядке.

транзакции это вообще отдельная тема и она не сюда

Добро пожаловать в мой любимый и одновременно бесячий мир serverless)

А что за собственный гейтвей?

Внутренняя разработка, не планируется в opensource (пока).
Kotlin, ktor, etc

ясно

Скорее даже мир lowcode. Который про "как делать плохие решения без помощи программистов"
Понятно, что в каком-нибудь ритейле в любом случае решения плохие, так что не важно, кто их будет делать )