AWS AppSync ожидает лямбда-функцию DynamoDB Streams, прежде чем разрешить подресурс

Question

У меня есть схема GraphQL, аналогичная следующей.В одном Браво есть несколько Альф, и каждый из них имеет ссылку друг на друга.(Браво может получить свои Альфы, а Альфа может получить свои Браво.)

type Alpha {
  id: ID!
  value: Int!
  bravo: Bravo!
}

type Bravo {
  value: Int!
  alphas: [Alpha!]!
}

input InputAlpha {
  value: Int!
}

type Mutation {
  putAlpha(alpha: InputAlpha): Alpha!
}

schema {
  mutation: Mutation
}

Как вы можете сказать, оба типа имеют значение.Значение Альфа произвольно, но значение Браво является суммой связанных с ним Альф.По причинам производительности (и стоимости) значение Bravo кэшируется в таблице DynamoDB и изменяется при каждом обновлении Alpha.

Альфы обновляются с помощью простого распознавателя AppSync DynamoDB PutItem, при этом предполагается, чтозначение его Bravo будет обновлено лямбда-функцией, наблюдающей за потоком таблицы.Это работает хорошо по большей части;Я могу поставить Альфы со случайными значениями, и я могу получить значение их Браво.

Проблема возникает, когда я пытаюсь запросить значение Браво в том же запросе.(Функция Lambda требует некоторого времени для обновления из потока.)

mutation putAlpha {
  putAlpha(alpha: {
      value: 10
  }) {
    id
    value
    bravo {
      value
    }
  }
}

Естественно, это возвращает старый кешированный value из bravo, потому что функция Lambda не была запущена к тому времениБраво разрешено.

Есть ли способ дождаться срабатывания лямбда-функции потока DynamoDB перед разрешением bravo или, возможно, сделать операцию PutItem синхронной?

Единственная альтернатива IМожно подумать о том, чтобы сделать putAlpha распознаватель лямбда-функцией вместо простого распознавателя и выполнить там логику обновления Bravo.

Является ли этот тип лямбды непрерывным обновлением значения кэша нормальным, или я делаю это?что-то не так?

Answer 1

Я думаю, что ваш клиент должен знать, что значение Браво рассчитывается в фоновом режиме.Если это не компромисс, который вы можете сделать, подумайте о том, чтобы переместить логику обновления Bravo в мутацию putAlpha.(Чтобы избежать условий гонки, вы можете использовать действие ADD UpdateExpression.)

Один из способов - это обновить значение Bravo через ваш API в вашем потоке и подписаться на обновления Bravo в вашем клиенте.Можно запустить aws-appsync в Lambda, хотя вам нужно указать window, xhr и т. Д.

Пара других способов:

1. Вы можете увеличить значение Bravo в кеше клиента вместовзяв его из ответа putAlpha.
2. Вы можете получить значение Браво после его обновления.(Вероятно, он будет обновлен через несколько секунд. Возможно, у вас есть способ проверить, была ли применена эта Альфа к Bravo, и может сработать сохранение времени обновления последней Альфы до Bravo.)

Answer 2

Если вы знаете, каким должно быть следующее значение Bravo при запуске updateAlpha (например, вам не нужно читать другие Alphas), вы можете использовать BatchPutItem для обновления обеих таблиц.

Если нет, я не верю, что AppSync полностью поддерживает этот вариант использования прямо сейчас.

Чтобы все заработало, нужно дождаться обновления записи Браво, прежде чем читать ее.Я думаю, что на данный момент самый простой способ - использовать функцию Lambda.

Некоторые другие вещи, которые вы можете попробовать (они немного забавны):

1. СделатьМеханизм разрешения мутаций putAlpha вращается в цикле в течение заданного промежутка времени, пока поток не обновит запись Bravo.
2. Добавьте преобразователь в Alpha.bravo, который ожидает X значения в шаблоне сопоставления запроса перед чтением из таблицы.
3. Добавить преобразователь в Bravo.value, который запрашивает все альфы, суммирует их значения, а затем возвращает суммированное значение.Этот вид поражает цель сохранения значения в Bravo.

Я не думаю, что вы можете использовать сон в резольвере, но вы можете использовать циклы: https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-programming-guide.html#loops

Надеюсь, это поможет!