Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Portability Review #725

Open
josephjclark opened this issue Jun 28, 2024 · 0 comments
Open

Portability Review #725

josephjclark opened this issue Jun 28, 2024 · 0 comments
Labels
design Design issues or discussion

Comments

@josephjclark
Copy link
Collaborator

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
@josephjclark josephjclark added the design Design issues or discussion label Jun 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Design issues or discussion
Projects
Status: New Issues
Development

No branches or pull requests

1 participant