I was randomly thinking about this last night. We don't talk about Portability much.
When designing the v2 runtime, we talked about portability a bit. It was an input to the design.
As we think about job writing 2.0 and even 3.0 I think we should keep this card on the table
What is portability?
Portability is ability to run your job code - your business logic - outside of the OpenFn platform.
Right? That's what it's gotta be. And I don't just mean the platform really, as in Lightning or even the CLI. I mean the whole stack. How do you run your job without even using kit?
And this is important because if I build a bunch of business processes into OpenFn, and then something happens to OpenFn (and things happen!), or maybe just a major OpenFn update really breaks the implementation. I need to take that business process I spend thousands (millions?) on and continue to use it.
Portability Notes
Just a brain dump at the moment
Compiled expressions are executable Javascript. You need the adaptor available using nodes module resolution algorithm, but at least the import statements tell you what you need
You can run a compiled expression through node.js and a very very minimal runtime.
Can you compile a a Workflow? Into a json object with compiled JS inside it? I don't think so? I think the CLI compile only works on expressions? I have to check
Can you compile a project.yaml? No.
We should create a CLI eject command, which takes an expression or workflow and compiles it all into a standalone npm package. This should include it's own, super minimal runtime (literally just the promise reducer) and adaptors in the dependencies. Probably the main execute function should be compatible with the runtime, so you can run it through @openfn/runtime, if you wanted to add that dependency (I suppose we can have commented out lines to compile and run through our own packages, allowing you to edit the workflow source)
The eject would help keep us honest - we should be able to run our workflows in an ejected form
I was randomly thinking about this last night. We don't talk about Portability much.
When designing the v2 runtime, we talked about portability a bit. It was an input to the design.
As we think about job writing 2.0 and even 3.0 I think we should keep this card on the table
What is portability?
Portability is ability to run your job code - your business logic - outside of the OpenFn platform.
Right? That's what it's gotta be. And I don't just mean the platform really, as in Lightning or even the CLI. I mean the whole stack. How do you run your job without even using kit?
And this is important because if I build a bunch of business processes into OpenFn, and then something happens to OpenFn (and things happen!), or maybe just a major OpenFn update really breaks the implementation. I need to take that business process I spend thousands (millions?) on and continue to use it.
Portability Notes
Just a brain dump at the moment
ejectcommand, which takes an expression or workflow and compiles it all into a standalone npm package. This should include it's own, super minimal runtime (literally just the promise reducer) and adaptors in the dependencies. Probably the main execute function should be compatible with the runtime, so you can run it through @openfn/runtime, if you wanted to add that dependency (I suppose we can have commented out lines to compile and run through our own packages, allowing you to edit the workflow source)