Использование AWS Appsyn c с AWS Нептун - PullRequest
Новая
       18

Использование AWS Appsyn c с AWS Нептун

3 голосов
/ 17 апреля 2020

В настоящее время я использую Aws Appsyn c, Aws Lambda и Aws Нептун для приложения. Моя лямбда-функция использует NodeJS 12. В настоящее время моя проблема заключается в том, чтобы вернуть соответствующий формат JSON из Нептуна (точнее, gremlin) для моего graphql api (appsyn c), когда я выполняю мутацию и, в конце концов, запрос (я хочу убедиться, что мутации работают в первую очередь). Например:

  1. Вот мой тип Post для моей схемы graphql с addPost мутацией прямо над ней: Post schema
  2. Мутация addPost отображается на этот преобразователь: Resolver Post Mutation
  3. , который затем запускает этот фрагмент кода: Лямбда-код

Когда я запускаю этот тестовый запрос для добавления сообщения, я получаю следующую ошибку с данными null : addPost тестовый запрос и результат

Возвращает ли добавление вершины в gremlin данные / объект? Если так, как я могу получить соответствующий JSON формат для моего appsyn c graphql api? Я читал Practical Gremlin и искал в Интернете, но не повезло. Заранее спасибо.

1 Ответ

3 голосов
/ 17 апреля 2020

Скорее всего, то, что вы видите, связано с несовместимостью в Lambda с форматом возврата по умолчанию для Node.js GLV. Возвращенный формат по умолчанию - GraphSONV3, который JSON -подобен, но не отформатирован JSON. Лямбда ожидает хорошо отформатированный JSON. Вы можете изменить mimetype при установлении соединения с Neptune, чтобы использовать GraphSONV2, с которым у Lambda не должно быть проблем. 

const dc = new DriverRemoteConnection(
  `wss://<neptune-endpoint>:8182/gremlin`,
  { mimeType: "application/vnd.gremlin-v2.0+json" } 
);

Другая вещь, которую нужно проверить, - это то, как вы решаете обещание, возвращаемое await. запрос Гремлин. В вашем примере кода похоже, что вы берете результат запроса await'd и передаете его в JSON .stringify (). Я не думаю, что это сработает, так как это эффективно вернет строковую версию Обещания JSON (что вы и видите). Что вы можете сделать в этом случае (если вы хотите отправлять запросы асинхронно), это взять ваши запросы Gremlin (или, может быть, даже этот более крупный оператор case) и поместить его в asyn c функцию вне обработчика Lambda. Пример: 

const gremlin = require('gremlin');
const DriverRemoteConnection = gremlin.driver.DriverRemoteConnection;
const Graph = gremlin.structure.Graph;

const dc = new DriverRemoteConnection('wss://<neptune-endpoint>:8182/gremlin',
    { mimeType: "application/vnd.gremlin-v2.0+json" }
    );

const graph = new Graph();
const g = graph.traversal().withRemote(dc);

async function callNeptune() {
    const result = await g.addV('Post').property('userId','someid').
        property('genre','somegenre').
        property('caption','somecaption').
        property('timestamp','sometimestamp').
        toList();
    console.log(result);
    dc.close();
    try {
        return result;
    } catch (error) {
        return error;
    }
}

exports.handler = async (event) => {

    const rawOutput = await callNeptune();
    const jsonOutput = JSON.stringify(rawOutput);
    const response = {
        statusCode: 200,
        body: jsonOutput,
    };
    return response;
};

В этом сценарии вы ожидаете, что функция asyn c с вашим запросом Gremlin через вызов await, который теперь находится в обработчике. Таким образом, вы можете взять полученные результаты и передать их в JSON .Stringify () и вернуть их. Служба Lambda разрешит обещание обработчика на этом этапе.

FWIW, использование async / await от уровня API с поддержкой Lambda до Neptune мало что дает. И функция Lambda, и серверные потоки Neptune будут ожидать (и удерживать ресурсы), пока все обещания не будут разрешены. Во многих случаях это может просто усложнить использование синхронных вызовов. Было бы по-другому, если бы вы делали это из долго работающего контейнерного приложения или из веб-интерфейса, где в то же время имеет смысл пускать другие процессы.

...