Skip to content

Change API design to more mature way and some refactoring suggestion #6

@darky

Description

@darky

I think, passing context as second parameter is wrong. API can't be scaled. For example, I want to support SharedArrayBuffer and need to pass it as third parameter for existing API. Maybe later, some additional parameters passed as fourth, fifth, e.t.c parameters.

Need to pass options object as second parameter and it can be scaled in more mature way.

Also, I think context, inspired from microjob, has ugly design:

for (const key in context) {
if (!context.hasOwnProperty(key) || !context[key]) continue
definition += `const ${key} = ${JSON.stringify(context[key])};\n`
}
const routineStr = `
async () => {
${definition}
return await (${handler.toString()})()
}

Maybe need to deprecate it and implement simple data, which received as parameter on "go function":

go(function({data}) {
  console.log(data.test) // 5
}, {data: {test: 5}})

It solution so friendly with TypeScript type inference via generics.

Also JSON.stringify(data) more performant instead it:

   for (const key in context) { 
     if (!context.hasOwnProperty(key) || !context[key]) continue 
     definition += `const ${key} = ${JSON.stringify(context[key])};\n` 
   } 

Also exists problem with dynamic function body:

async () => {
  ${definition}
  return await (${handler.toString()})()
}

And eval of it can't be cached for high-load purpose applications and V8 JIT can't properly optimise it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions