Simplify functions to the core.... Convention over configuration at the fore front.

[rdallman]

In gitlab by @hibooboo2 on May 18, 2017, 09:55

So my thoughts on the whole functions idea of dev is:

• The following should be drop dead simple:
  • Create a function
  • Testing the functions
  • Publishing the function
  • Testing the functions that have been published
  • Creating an app should be easy
    • Apps should be easy to create / deploy multiple functions to create an entire api / application
  • I should be able to create an application / app (eg group of functions)
  • You should only need to run one command to create an application and deploy it.

In order to meet all of these reqs I think that when you run fn init if there is no app / function configured in the current directory we create one. This discovery should discover all the functions that create an application and publish it all. That means there needs to be a sane way to do that. Right now we can init to create a functions and auto deploy to an app. However it requires us to specify the name of the app. I think that it should be similar to https://zeit.co/now#get-started in the most basic case. To accomplish this I want to kind of expand / add to what @treeder Has said in #10

These are the things I think that fn init or deploy should do if there currently exists no function / app in the current git repo or directory depending on which it is. That being said I have two flows I would propose:

I think first it should just try it using the current directory:

• discover all the functions possible and recurse in to directories.
• Naming the app and functions.
  • currently we name the function based on the current folder / what ever the docker image is that we have provided on fn init.
  • I think that there should be a sane way to name the functions and app with no info in the command.
  • to do this I was thinking that we use the folder name as the name of the app and we can discover functions like this:
    • instead of func.go or func.java we do :
      • *.func.langextension
  • this allows us to easily auto discover functions in the same directory and figure out their runtimes easily with no input.

Here is an example:

$ tree
.
├── admin
│   └── allpolls.func.py
├── getpoll.func.go
├── getresults.func.go
├── makepoll.func.go
├── polls.func.rb
└── vote.func.java

1 directory, 6 files

That would give us 6 functions and grouped into an app called strawpoll since the folders name was strawpoll. The thing I am not sure on is the format for app.yaml and how we would name the func.yamls. Was thinking maybe changing it to .fx.yaml and then we can put the function name in front of the .fx.yaml

And then from there you would be able to change the values in the yamls etc...

[rdallman]

In gitlab by @rdallman on May 18, 2017, 10:15

disagree about this Naming the app and functions. part. picking the current directory name is pretty sane for a default, i think. in the app file itself we could probably make it easy to change the name from the default (so still "convention over configuration") but then i think things get really complicated (well, not intuitive). don't like people having to make files named certain things with our own extension, I think it smells and will turn people off -- if there's an app / func definition file then it's pretty obvious that it's functions stuff.

app.yaml and how we would name the func.yamls

func.yaml and app.yaml seem fine ? having docker image names in file names will be horrid. e.g. http://my-private-registry.company.com/1/registry/mythingajig/yodawg:0.0.1.fx.yaml ? idk i don't like the idea of having all these little DSL files laying around either but I can't think of a better alternative.

[rdallman]

In gitlab by @treeder on May 18, 2017, 10:23

I agree for the most part except for the naming thing. Pretty similar thoughts as Reed. Function per directory seems the best to me as typically it won't just be a single file, there will almost always be dependencies and other things that function might need like it's own Dockerfile, it's own metadata in func.yaml, etc.

[rdallman]

In gitlab by @hibooboo2 on May 18, 2017, 14:48

Ok so if it is a function per folder then at the top level if you have a git repo the base folder of the git repo would be the app name?