Actualmente uso Aws Appsync, Aws Lambda y Aws Neptune para una aplicación. Mi función Lambda usa NodeJS 12. En este momento, mi problema es recuperar el formato JSON apropiado de Neptune (más específicamente, gremlin) para mi api de graphql (appsync) cuando hago una mutación y, finalmente, una consulta (quiero asegurarme de que las mutaciones sean trabajando primero). Por ejemplo:
Cuando ejecuto esta consulta de prueba para agregar una publicación, aparece el siguiente error y los datos son nulos : consulta de prueba addPost y resultado
¿Agregar un vértice en gremlin devuelve datos/un objeto? Si es así, ¿cómo obtengo el formato JSON apropiado para mi appsync graphql api? He estado leyendo Practical Gremlin y buscando en la web, pero no tuve suerte. Gracias de antemano.
Lo más probable es que lo que está viendo esté relacionado con una incompatibilidad en Lambda con el formato de retorno predeterminado para Node.js GLV. El formato predeterminado devuelto es GraphSONV3, que es similar a JSON pero no tiene un formato JSON correcto. Lambda espera JSON bien formateado. Puede cambiar el tipo MIME al establecer su conexión a Neptune para usar GraphSONV2, con el que Lambda no debería tener ningún problema.
const dc = new DriverRemoteConnection( `wss://<neptune-endpoint>:8182/gremlin`, { mimeType: "application/vnd.gremlin-v2.0+json" } );La otra cosa a validar es cómo está resolviendo la promesa devuelta por la consulta esperada de Gremlin. Parece que en su código de muestra está tomando el resultado de la consulta esperada y introduciéndolo en JSON.stringify(). No creo que eso funcione, ya que efectivamente devolverá la versión JSON stringified de Promise (que es lo que está viendo). Lo que puede hacer en este caso (si desea enviar consultas de forma asíncrona) es tomar sus consultas de Gremlin (o tal vez incluso esta declaración de caso más grande) y ponerlas en una función asíncrona fuera del controlador de Lambda. Ejemplo:
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; };En este escenario, está esperando la función asíncrona con su consulta de Gremlin a través de una llamada en espera que ahora está en el controlador. Entonces puede tomar los resultados de eso e introducirlos en JSON.Stringify() y devolverlos. El servicio de Lambda resolverá la promesa del controlador en ese punto.
FWIW, hay pocos beneficios al usar async/await desde una capa API respaldada por Lambda a Neptune. Tanto la función Lambda como los subprocesos del lado del servidor de Neptune estarán esperando (y reteniendo recursos) hasta que se resuelvan todas las promesas. En muchos casos, esto puede agregar complejidad al uso de llamadas sincrónicas. Sería diferente si estuviera haciendo esto desde una aplicación en contenedor de ejecución prolongada o desde un front-end basado en web, donde tiene sentido dejar otros procesos mientras tanto.