Konnectors should be run through a runner from cozy-konnector-libs instead of running code directly

[ptbrowne]

Greg has shown us a runner that expects an interface to run konnectors that would be coupled to a runner that would orchestrate the run of a konnector. This decouples the instrumentation (LOGIN_OK, LOGIN_FAILED, SYNC_SUCCESSFUL) of the konnector from its implementation.

import { run } from 'cozy-konnector-libs'

run({
  login: function () {
    return request(....)
  },

  sync: function () {
    return request(....).then(addData)
  }
})

The run function then can instrument the konnector without changing its implementation.

const runTask = async (msg, fn) => {
  try {
    await realtime(msg + '_START')
    await fn()
    await realtime(msg + '_OK')
  } catch (e) {
    await realtime(msg + '_FAILED')
    process.exit(1)
  }
}

const run = async konnector => {
    await runTask('LOGIN', konnector.login())
    await runTask('SYNC', konnector.sync())
}

It also enables a possible batch runner to run simultaneously konnectors.

[gregorylegarec]

Thanks for opening this issue @ptbrowne. What I had in mind was to use an inversion of control pattern. The idea is to let cozy-konnector-libs run the konnectors in a way or another.

This could improve

• konnector development (less code for contributor, less dependencies and no instanciation)
• testing and mocking (cozy-konnector-libs could provide a set of tests to validate a konnector signature, or test directly a call by mocking internal method for fetching for example)

My first POC is on this branch on the debug konnector. I also started a full working example for Trainline but the code is not in the computer I am working with right now. I will share this example in one week.

[ptbrowne]

Yes I am OK with the inversion of control. This is what is shown with the run function. At the end, it would not be the user that would directly call it. The user of cozy-konnector-libs would only export the interface. We would at first expose the run function to have a smooth transition path.

[doubleface]

I am also OK with the inversion of control but it is important to make the migration path the easiest.