Let developers to call JS methods on limited JS objects about askql HOT 9 CLOSED

@pkarw seems like this can be done in user space with a resource factory that accepts an object, for example:

  function myResourceFactory(module) {
    const res = {}
    Object.keys(module).forEach((k) => {
      res[k] = resource({
        type: any,
        async resolver(...args: any) {
          return module[k](...args);
        },
      });
    });
    return res;
  }

  const result = await askql.runUntyped(
    {
      resources: {
        ...myResourceFactory(lodash),
        ...askql.resources,
      }
    },
    askql.parse("ask { 'hello world!' }")
  );

The design decision with AskQL was to have a separate computing environment from JavaScript (or any other host programming language) and therefore it would be troublesome to do a direct linking. All callable host methods would need to go through an explicit wrapper which allows for security measures. With the method above it perhaps becomes easier to add multiple resources at the same time.

Although, for full support of what you're asking for with namespaces would need to solve #579 first.

from askql.

Sounds good. In case of lodash probably there are no harmful functions, but in general it would be good to have jsModuleInterop.

from askql.

Cool! Any insights on how can we implement this feature? I was looking at the run method inside the vm implementation. Is it the right hook-up point to extend it? I mean we could potentially implement a "hack": to check the 1st parameter of any function call (as it should be the processing resource): if there is a proper child function - lets' call it. However, it's not an ideal one. I mean when these functions are going to return JS objects (chaining) we'd be not able to use it further.

from askql.

I envision jsModuleInterop the following way:

const vmContext = { 
  customResources: [ 
   'lodash': jsModuleInterop('lodash', ['sort', 'unique'])` 
  ]
...
}

What jsModuleInterop(arg1, args) would be is a helper that creates a resource which has properties listed in args that are wrappers over functions with the same names from module arg1.

from askql.

This way we don't need to add a hack with additional checks for function names in runtime. We use an existing mechanism instead.

from askql.

That's cool, however I've got an additional question. What do you mean by resource properties? I mean at the moment one resource could have just a single execute and secondly resolve method - so no additional properties could be set. Or am I wrong?

from askql.

@czerwinskilukasz1 maybe another option would be to add a support for something like JS scripting inside AskQL? I mean something like:

js { 
}

when used within the AskScript the JS interpreter like jerryScript or JS-interpreter is being used to execute the scope - isolated from the main Node process.

from askql.

That's cool, however I've got an additional question. What do you mean by resource properties? I mean at the moment one resource could have just a single execute and secondly resolve method - so no additional properties could be set. Or am I wrong?

Actually, I should have written 'dictionary' rather than 'resource', so that lodash.sort in AskScript would be a function for sorting, lodash.unique would be a function for unique values etc.

@czerwinskilukasz1 maybe another option would be to add a support for something like JS scripting inside AskQL? I mean something like:

js { 
}

when used within the AskScript the JS interpreter like jerryScript or JS-interpreter is being used to execute the scope - isolated from the main Node process.

If we allow to run an arbitrary Javascript code, we would need to make sure that it cannot make nasty things on the server, e.g. access files, write/read files, open ports etc., e.g using os or net packages, which are available by default. Then, we would need to either whitelist only specific packages or block any require() / import at all. In any case, we would run in the whole class of issues we would run if we wanted to run a Javascript interpreter in the first place. Not sure if we want to focus on it now.

from askql.

Perfect fit @mhagmajer. Thanks!

from askql.