No way to write initialization and finalization code with built-in resolvers.js

[harleyguru]

It's common practice to write initialization process like db connection (opening db connection and reuse it in handler function) at the top of handler function and write finalization process like db closing (closing db connection before lambda container would be destroyed). How could we do it with resolvers.js because this resolvers.js wouldn't include handler function definition?

[harleyguru]

Again, I have no idea with the context of executing this resolvers.js in actual Lambda function. That makes it difficult to understand where to place the code in this resolvers.js

I'd like to get the clarification the programming model of this resolvers.js in the relation with Lambda handler function. Thanks

[harleyguru]

I see this component is requiring resolvers.js module in handler function whenever Lambda will get the request. The big reason why using Lambda Data Source is the flexibility to integrate with not supported data sources like Graph DB or MongoDB etc. I think this should be a big problem.

[harleyguru]

No update from anyone?

[eahefnawy]

Hey @harleyguru ... sorry for the late reply here. I'm not receiving notifications from this repo for some reasons 🤔

Regarding your question, the high-level resolvers file is meant to simplify things by abstracting the lambda details (handler, event...etc). However, I definitely understand your issue.

I think the solution here is to either to allow users to provide a raw handler instead of the resolver file for cases like this, or have a lower-level app sync component that does not abstract much for maximum flexibility. Do you think that would solve your issue?

[harleyguru]

@eahefnawy Thanks for your kind response, I've been waiting for your response long time since I am using serverless components actively for our project recently and loved your good job a lot! Yeah, I've solved this issue myself already by writing lambda component myself. I had to use lambda component and reference its output in this graphql component since lambda configuration of this component didn't provide all features I need. aws-lambda component has also some limitation with itself like not deploying right IAM role for VPC usecase, missing scheduling feature etc.

[mwawrusch]

If I understand this correctly we need to create a separate package for each individual lambda, and then manually stitch those lambdas into the graphql component? This was way easier in the now depreciated older version.

[hypexr]

@mwawrusch That is the way I started doing it, but in the end switched to creating multiple graphql components and hooking them together by passing the appId in serverless.yml, like:

  apiId: ${output:${stage}:${app}:base.apiId}

So my component named base deploys the appsync api and the schema and the other graphql components extend it for each "service".

Instead of having everything as individual lambdas, we've grouped them together into services with resolver.js referencing the individual queries, mutations, and subscriptions:

const createUser = require ('./createUser');
const getCurrentUser = require ('./getCurrentUser');
const getFavoriteCropCandidates = require ('./getFavoriteCropCandidates');
const updateUser = require ('./updateUser');

const Query = {
  getCurrentUser: apiCommon.runHandler (getCurrentUser.handler),
  getFavoriteCropCandidates: apiCommon.runHandler (getFavoriteCropCandidates.handler),
};

const Mutation = {
  createUser: apiCommon.runHandler (createUser.handler),
  updateUser: apiCommon.runHandler (updateUser.handler),
};

module.exports = { Query, Mutation };

where our runHandler is just setting up some stuff like a logging prefix and common exception handling.