Colocated function deployments #11
Description
From @DavidWells in #1 (comment)
This would for sure be an improvement on the current status quo.
There are a couple more things to consider:
What about colocated functions?
If I have an API with a bounded context of "users" I would probably keep those in the same folder because they share similar dependancies, DB connections, shared utility functions etc.
| - api/
| - api/users
| - api/users/package.json # shared deps that get and delete both use
| - api/users/get.js
| - api/users/delete.js
| - api/other-concern # different context with different deps
| - src # frontend code
| package.json #frontend deps
This is how larger apps manifest themselves with similar functions grouped/located near the others.
If we go with this better convention based approach I won't be able to put functions next to each other where they belong. Instead every function needs its own folder and duplicated package.json file. This will quickly become a nightmare to maintain.
If we don't support larger ("real") application file structures, this will be the point when users eject out of Netlify functions for a more robust function tool that allows them to structure the code that makes sense for them. (IE whatever structure they desire, REST support, Function configuration for timeout, regions, etc)
The solution to this problem is function configuration and having users explicitly define where their function entrypoints are.
We can default to this better convention based lookup, but we should also allow for users to define their function entry points, the timeouts, regions, runtime, etc in a configuration file (probably netlify.toml)
The configuration in toml would be something like:
[functions]
[functions.userRead]
handler = "./api/user/get.js"
timeout = 30.0
[functions.userDelete]
handler = "./api/user/delete.js"
region = "us-east-2"The configuration approach gives ultimate flexibility on how applications can be build. The zip-and-ship would package from the handler path in that case