{"action":"created","issue":{"url":"https://api.github.com/repos/fnproject/fn/issues/817","repository_url":"https://api.github.com/repos/fnproject/fn","labels_url":"https://api.github.com/repos/fnproject/fn/issues/817/labels{/name}","comments_url":"https://api.github.com/repos/fnproject/fn/issues/817/comments","events_url":"https://api.github.com/repos/fnproject/fn/issues/817/events","html_url":"https://github.com/fnproject/fn/issues/817","id":302853128,"number":817,"title":"Proposal: Splitting functions from routes","user":{"login":"treeder","id":75826,"avatar_url":"https://avatars3.githubusercontent.com/u/75826?v=4","gravatar_id":"","url":"https://api.github.com/users/treeder","html_url":"https://github.com/treeder","followers_url":"https://api.github.com/users/treeder/followers","following_url":"https://api.github.com/users/treeder/following{/other_user}","gists_url":"https://api.github.com/users/treeder/gists{/gist_id}","starred_url":"https://api.github.com/users/treeder/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/treeder/subscriptions","organizations_url":"https://api.github.com/users/treeder/orgs","repos_url":"https://api.github.com/users/treeder/repos","events_url":"https://api.github.com/users/treeder/events{/privacy}","received_events_url":"https://api.github.com/users/treeder/received_events","type":"User","site_admin":false},"labels":[{"id":655834948,"url":"https://api.github.com/repos/fnproject/fn/labels/for%20discussion","name":"for discussion","color":"A295D6","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/fnproject/fn/milestones/10","html_url":"https://github.com/fnproject/fn/milestone/10","labels_url":"https://api.github.com/repos/fnproject/fn/milestones/10/labels","id":3058414,"number":10,"title":"Version 1.0 - Lock in API's and other contracts","description":"","creator":{"login":"treeder","id":75826,"avatar_url":"https://avatars3.githubusercontent.com/u/75826?v=4","gravatar_id":"","url":"https://api.github.com/users/treeder","html_url":"https://github.com/treeder","followers_url":"https://api.github.com/users/treeder/followers","following_url":"https://api.github.com/users/treeder/following{/other_user}","gists_url":"https://api.github.com/users/treeder/gists{/gist_id}","starred_url":"https://api.github.com/users/treeder/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/treeder/subscriptions","organizations_url":"https://api.github.com/users/treeder/orgs","repos_url":"https://api.github.com/users/treeder/repos","events_url":"https://api.github.com/users/treeder/events{/privacy}","received_events_url":"https://api.github.com/users/treeder/received_events","type":"User","site_admin":false},"open_issues":8,"closed_issues":3,"state":"open","created_at":"2018-01-23T18:34:11Z","updated_at":"2018-03-27T18:18:30Z","due_on":"2018-02-16T08:00:00Z","closed_at":null},"comments":20,"created_at":"2018-03-06T20:27:28Z","updated_at":"2018-03-29T20:39:28Z","closed_at":null,"author_association":"OWNER","body":"While talking with @vshiva , the concept of functions being separate from routes came up and it got me thinking a bit. \r\n\r\nCurrently, a `route` is both a function definition and an HTTP route to that function. But what about when you don't want or need an HTTP route to the function?  \r\n\r\nA `function` needs the container image reference, format, memory, timeout, etc. It doesn't care about HTTP or what protocol is being used to call it, it's only dependency is a Docker registry. \r\n\r\nA `route` as it is right now needs things like: path, image name, some HTTP specific things like content-type. If we separate functions, then it would need a reference to a function which isn't simply a Docker image URL. \r\n\r\nWhat's the benefit?  Well as @vshiva pointed out, say you have a UI that lets you tie things together: \"when X happens, run this function with X's event data\". How that's hooked together behind the scenes doesn't really matter to the user, could be via a message queue, could be a webhook. \r\n\r\nThis got me thinking of the decades old \"function hub\" conversations (cc @carimura), but perhaps more of a \"function registry\". In it's simplest form, it would just be a way to CRUD a function object with the things above. Then when we create routes, we give it the function URL which is a reference into the registry. This could be a separate API in itself, but probably build it into Fn initially. \r\n"},"comment":{"url":"https://api.github.com/repos/fnproject/fn/issues/comments/377362461","html_url":"https://github.com/fnproject/fn/issues/817#issuecomment-377362461","issue_url":"https://api.github.com/repos/fnproject/fn/issues/817","id":377362461,"user":{"login":"rdallman","id":2935111,"avatar_url":"https://avatars0.githubusercontent.com/u/2935111?v=4","gravatar_id":"","url":"https://api.github.com/users/rdallman","html_url":"https://github.com/rdallman","followers_url":"https://api.github.com/users/rdallman/followers","following_url":"https://api.github.com/users/rdallman/following{/other_user}","gists_url":"https://api.github.com/users/rdallman/gists{/gist_id}","starred_url":"https://api.github.com/users/rdallman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rdallman/subscriptions","organizations_url":"https://api.github.com/users/rdallman/orgs","repos_url":"https://api.github.com/users/rdallman/repos","events_url":"https://api.github.com/users/rdallman/events{/privacy}","received_events_url":"https://api.github.com/users/rdallman/received_events","type":"User","site_admin":false},"created_at":"2018-03-29T20:29:13Z","updated_at":"2018-03-29T20:29:13Z","author_association":"MEMBER","body":"thanks for replies. immediate one that sticks out is:\r\n\r\n> So, Fn should have an API endpoint that describes available triggers (http, kafka, grpc, mqtt, etc.) and there should be an API to build an association between the function and the trigger (user can create 2 grpc paths to call the function, user wants to call a function by pushing the message into 2 different topics and so on).\r\n\r\nintuitively it seems like a trigger is the one that glues some thing like a queue or a route to a function, not fn server itself. it's hard to think about making a generic binding that works for every trigger type that would be nice to work with, and it also doesn't seem like fn server necessarily cares about this association, if it simply consumes events and outputs them. the thinking is that each trigger has its own way of mapping its specific ingest points onto functions, and the api could be there; for http, this could be a url path, for instance (as it is now). to the user, if we by default have an embedded gateway that has this `url path -> function` mapping, we keep the behavior we have now, but the route mapping is pushed into the gateway, and not in fn server itself (as now). anyway, seems odd to have fn server store triggers and mappings, and the ux might get pretty bad trying to do it generically. thoughts?"}}
{"actor":{"display_login":"rdallman"}}