Should first parameter for http triggers be route or function name

[ejizba]

Some feedback here from @ChuckJonas

Is the first parameter the route? Or just the function name? I'm hoping it's the former as this would make it similar to other popular JS frameworks.

Fwiw, we did have the route as the first parameter in one of the prototypes (see here), but we got mixed feedback on that. Sure, it's more similar to express, but a lot of people view the function name as very important. Our initial decision was to use the function name for the sake of simplicity and to be consistent with other triggers. We are considering a true express.js programming model and that may be the better place to use route as the first parameter, tracked here: #16

[ChuckJonas]

understandable... Honestly, it's easy enough to transform the signature to whatever format best fits your needs anyways

const { app as azureApp, Application, HttpFunction } = require("@azure/functions");

const makeExpressLike = (app: Application) => ({
  get: (url: string, handler: HttpFunction) => app.http(nameFromUrl(url), {
     methods: ['GET'],
     handler
  }),
 //  post: ...
});

const app = makeExpressLike(azureApp);

app.get('/hello', () => async (context, request) => {
    context.log('Http function processed request');

    const name = request.query.get('name') 
      || await request.text() 
      || 'world';

    return { body: `Hello, ${name}!` };
 });
 

[aaronpowell]

but a lot of people view the function name as very important

That's interesting @ejizba, do you have any reasoning as to why that's seen as important?

[ejizba]

That feedback was primarily from existing functions users, fwiw. I think the primary reason was for application insights logs and just telemetry in general - the data is always organized by the function name. The other reason was that the function name is used heavily in the portal (mostly for organization reasons in the UI).

I would say existing users were very confused if we did not ask for a function name, but new users were only mildly confused if we did ask for the name. The function name seemed much less confusing than other function-isms like bindings. My general feeling was that removing the function name was a step too far for the default model just because of how ingrained it is in the Functions ecosystem as a whole

[ChuckJonas]

I would say existing users were very confused if we did not ask for a function name, but new users were only mildly confused if we did ask for the name. The function name seemed much less confusing than other function-isms like bindings. My general feeling was that removing the function name was a step too far for the default model just because of how ingrained it is in the Functions ecosystem as a whole

I will say that doesn't really align with my experience... From what I can tell, you can't even choose the name. It autogenerates it from the name of the folder it's in.

Of course you would need to allow defining the name as an option, but it might actually be a nice feature to not have to provide one. Instead it could be defaulted using method and route: ${method}-${route}. This would provide a nice naming convention out of the box.

I am actually confused by the example though... Since you don't actually provide a route, what uri would the function actually be served on?

[ejizba]

From what I can tell, you can't even choose the name. It autogenerates it from the name of the folder it's in.

Yes this was true in the old programming model. However, most tooling (VS Code, func cli, etc.) asked you to pick the function name as the first prompt when creating a function. You could also change the folder name at any point. We all agree that was an annoyingly strict naming convention, but I wouldn't say you "can't choose" it or that it's "autogenerated".

Instead it could be defaulted using method and route: ${method}-${route}. This would provide a nice naming convention out of the box.

If only it were this easy 😮‍💨 I'm not sure we can pick an accurate name due to complicating factors like these:

• The route can have parameters (for example products/{category:alpha}/{id:int?})
• The route can be affected by a routePrefix from your host.json file
• You can have multiple methods
• What about non http triggers?

I am actually confused by the example though... Since you don't actually provide a route, what uri would the function actually be served on?

The new and old programming models have the same behavior for this. The uri is "api/<function name>". The route is an optional parameter on the options object (all of the properties that used to be in "function.json" are now supported on the options object). For example:

app.http('helloWorld1', {
    methods: ['GET', 'POST'],
    route: '/alternative/route',
    handler: (context, request) => { ... }
});

[ejizba]

originally posted by @aaronpowell in #35

Since the Function Name parameter to a HTTP Trigger registration (in v4 programming model) is used to define the route, when you provide a HttpFunctionOptions argument rather than a callback, it seems confusing as to why you might want to provide both a name and route.

I'd prefer to be able to do the following:

// name becomes route
app.get('hello-world-1', (_, req) => ({ body: "Hello World" });

// explicit route, with name derived from route
app.get({
  route: '/hello-world-2',
  handler: (_, req) => ({ body: "Hello World" })
});

// name and route defined
app.get({
  route: '/hello-world-3',
  handler: (_, req) => ({ body: "Hello World" }),
  name: "Hello World 3
});