Using custom functions

1

Hi, few question about custom functions:

  • When using invoke-local with a custom resolver it seems ctx in undefined , is there a way to get ctx.api.gqlRequest to work using invoke-local ?
  • How can variables be passed to ctx.api.gqlRequest in custom functions?
  • Any way a debugger can be attached when executing invoke-local ?
2

Hey @chanand!

  1. Currently, ctx is undefined when developing locally. This is a feature improvement that we’re actively working on, as we build out our local development tools. If you want to make a custom API module locally, you can always use that to run calls while in development. However, will try to get the ctx argument included sooner than later!

  2. For variables, is this what you’re looking for?

 ctx.api.gqlRequest(QUERY, { ...variables });

Let me know and I can help point you in the right direction.

Working on a clean solution for the debugger right now! Ours is a bit messy :wink:

3

@chanand here’s the best solution we have, currently, for debugging in Node. It requires that you have a Chrome browser.

First, add this script to the project’s package.json file:

  "scripts": {
    "debug": "node --inspect $(npm root -g)/8base-cli/dist/index.js "
  }

Essentially, it runs node --inspect, and then finds the global npm 8base-cli package on your machine, building a path to the executable. Whether you’re using yarn or npm won’t matter.

To run a debugger with the 8base command, you then can now use:

npm run debug invoke-local FUNCTION_NAME -p /path/to/mock.json
// or
yarn debug invoke-local FUNCTION_NAME -p /path/to/mock.json

However, you’ll need to open Chrome and go to chrome://inspect. Click the Open dedicated DevTools for Node link.

The window where you’re debugger will be stopped! Now if you put a debugger in your code, it will pause execution at the appropriate line!

export default async (event: any, ctx: any) : Promise<LocalizeResult> => {
  // some code
  debugger;
  // more code.
};

There is one caveat that you’ll need to be aware of here. The code being debugged is the built code, which is why the script being debugged will look pretty unfamiliar.

Know that you have full access to the same scope, but any imported modules or function arguments might be assigned different names. If you want to inspect a module, it’s better to assign it to a variable so that the name will be the same. For example;

import AWS from 'aws-sdk';

export default async (event: any, ctx: any) : Promise<LocalizeResult> => {
  // Want to inspect the AWS module?
  const aws = AWS;
  // Now in the debugger you can be sure aws variable is available.
  debugger;
  // more code
};

Let me know any questions about this!

4

Thank you @sebastian.scholl, I’m not sure this is very useful without the ctx :slight_smile:

5

I get it :wink:

Know that ctx.api makes API calls, so if you need to do that, you can currently make a simple api module to handle the requests! Even name it ctx.api.gqlRequest.

Either way, I’m pushing the guys to add ctx asap to invoke local.

6

Any update here? Would be super useful to have