API-шлюз как интеграция с прокси-сервером DynamoDB и Integration Response для переменной Map возвращает - PullRequest
Новая
       54

API-шлюз как интеграция с прокси-сервером DynamoDB и Integration Response для переменной Map возвращает

1 голос
/ 01 февраля 2020

Учитывая AWS сервисную интеграцию (DynamoDB) в шлюзе API, мне интересно, есть ли способ динамически анализировать DynamoDB-структурированный JSON и возвращать его в стандартном JSON формате БЕЗ автономный лямбда-картограф? Для упрощения демонстрации приведу пример двух возможных элементов данных, существующих в моей таблице DynamoDB, которые я хотел бы вернуть в стандартном формате JSON с использованием одного шаблона отображения ответа интеграции, если это возможно:

Пример. 1 

{
    "id": "1",
    "desc": "here's a string type at depth 1",
    "info": {
        "key1": "a string at depth 2"
    }
}

Пример. 2 

{
    "id": "2",
    "desc": "here's a string type at depth 1",
    "info": {
        "key1": "a string at depth 2"
        "key2": {
            "subkey1": "look, a string at depth 3"
        }
    }
}

На основе этих двух примеров мы можем видеть, что это вложенные структуры данных, которые имеют общие ключи верхнего уровня, но имеют переменное количество вложенных уровней.

Я отметил во всех ответах на вопросы, касающиеся шаблонов сопоставления интеграции БЕЗ с использованием отдельной лямбда-функции для разрешения сопоставления:

  1. Анализ шаблонов сопоставления ответов интеграции для "плоских" данных DynamoDB - например, что-то вроде этого, где фактически глубина данных равна 1, поскольку все элементы данных имеют базовые c типы, такие как S или N: 
{
    "param1": "some stuff",
    "param2": "other stuff"
}
Любые ответы, относящиеся к более сложным типам данных, таким как M, предполагают, что автор вопроса без сомнения точно знает, как выглядят элементы таблицы DynamoDB. Поэтому они скажут что-то вроде «создайте шаблон сопоставления для каждого из слоев с соответствующим ожидаемым типом возврата для этого поля». Используя Ex. 1, чтобы проиллюстрировать решение Шаблон отображения ответа интеграции: 
#set($inputRoot = $input.path('$'))
{
    "id": "$input.Item.id.S",
    "desc": "$input.Item.desc.S",
    "info": {
        "key1": "$input.Item.info.M.key1.S"
    }
}

Теперь, это работает, если мы действительно знаем, какие ожидаемые поля результатов DynamoDB будут для каждой глубины и сколько уровней имеет каждый элемент таблицы - - то есть данные в таблице № SQL должны быть структурированы? Если не существует какой-либо версии метода AppSyn c VTL resolver $util.dynamodb.toJSON, которая может эффективно разворачивать динамические формы возвратов DynamoDB, есть ли способ сделать это напрямую, не используя отдельную лямбда-функцию? Есть ли способ обобщить шаблон сопоставления ответов для учета переменных данных типа M?

Одна из идей, которые у меня были, - это l oop через все ключи и отправка * 1033. * вводит вторичную l oop, но это кажется непрактичным, учитывая:

  1. количество итераций, которые теоретически могут потребоваться для развертывания глубоко вложенного объекта (DynamoDB может поддерживать до 32 слоев, в последний раз я проверял) и
  2. изменчивость вложенности от элемента к элементу в таблице.

К точке 1 #foreach имеет жесткое ограничение на число итераций он ограничен: 1000 https://forums.aws.amazon.com/thread.jspa?threadID=225222

Я сомневаюсь в перспективах не-лямбда-решения, но все же любопытно. Мысли?

...