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

Get rid of host.json #598

Open
hossam-nasr opened this issue Jun 18, 2022 · 0 comments
Open

Get rid of host.json #598

hossam-nasr opened this issue Jun 18, 2022 · 0 comments

Comments

@hossam-nasr
Copy link
Contributor

hossam-nasr commented Jun 18, 2022

This issue is also related to the new programming model we're currently working on, but probably is outside the scope of this effort.

In the same way we're getting rid of the need for function.json files with the new programming model, and allowing the worker to provide the necessary metadata to the host, we could also git rid of the host.json file, and supply whatever metadata there to the host through the worker. An example would be:

const app = new FunctionApp(/* contents of host.json */);

app.addTimerFunction('TimerTrigger1', { schedule: '0 */5 * * * *', }, timerTrigger1);

This would get rid of an extra configuration JSON file, allow users to reduce boilerplate, by us providing defaults when appropriate, and providing intelliscence for host.json properties. However, this would require significant changes on the Functions Host side, since currently only the host is able to read host.json files, and the settings there are needed to configure some Host settings, before even spinning up a language worker. If work is done on the Host side to enable an alternative workflow, this may also impact cold start times. All this would be to ultimately get rid of one configuration file, as opposed to potentially hundreds of function.json files.

This issue is to collect feedback and discussion around this proposal and whether it's worth investing time and resources into.

@hossam-nasr hossam-nasr added the v4 model 🚀 Related to the new V4 programming model label Jun 18, 2022
@ejizba ejizba added this to the Backlog Candidates milestone Jun 21, 2022
@ejizba ejizba removed the v4 model 🚀 Related to the new V4 programming model label Jul 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants