Description
I propose we split the worker up into two pieces, one that ships as-is with the host and one that ships as a separate node module (from here on out, I will reference these as the "core" and "programming model" packages respectively). This specific issue is to track moving the existing programming model out of the worker and into a separate package. The first iteration of this package should exactly replicate what the worker does today. The second iteration should be an improved programming model as tracked by #480.
When I say "programming model", this includes anything that makes our user's lives easier like parsing/converting/handling data from the host. Another way to think about it is if there is currently a type for something in our types package (Context, HttpRequest, etc.), the underlying code for that should probably be in the programming model package. The only thing left in the worker will likely be setting up and managing the gRPC channel used to communicate with the host
The Split
| Core worker package ("@azure/functions-core") | Programming model package ("@azure/functions" - name TBD) |
|---|---|
| Tracked by #567 | First version tracked by this issue |
| Required - we have to create an API in some form | Optional - we do not need this package. Instead, we could put everything in the core api |
| built-in module shipped with the worker - not listed in user's package.json | shipped with the user's app - listed in their package.json dependencies |
| slow to update because it relies on the host release cycle | fast to update - just publishing an npm package |
| forced on the user when it does update | user decides when to take the update |
| backwards compatability is paramount | backwards compatability is nice, but we can easily do a new major version |
| barebones API, very unopinionated | fancy api with lots of nice intellisense, can be opinionated |
Benefits
- When we make breaking changes (like this), users will be able to choose when they integrate those changes as opposed to us forcing it on them in Azure.
- If we ever want to force a breaking change on the user, all we have to do is change the "default" programming model package used in Azure, but users can still reference the old version in their own app.
- We can easily support multiple different programming models in their own packages (whether they're created by us or other people) at the same time. This PR is one example where we run into difficulties today because our various models are combined into the worker.
- Since both JS and TS users will need the npm package to run their app, they will both get the same experience of intellisense in VS Code