Comments (6)
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
androute
:${method}-${route}
. This would provide a nice naming convention out of the box.
If only it were this easy
- 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) => { ... }
});
from azure-functions-nodejs-library.
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}!` };
});
from azure-functions-nodejs-library.
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?
from azure-functions-nodejs-library.
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
from azure-functions-nodejs-library.
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?
from azure-functions-nodejs-library.
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
});
from azure-functions-nodejs-library.
Related Issues (20)
- When will Release version 4 of the Node.JS programming model for Azure Functions? HOT 1
- Tutorial HttpTrigger typescript V4 example doesn't register function locally HOT 1
- v4 doesn't detect my functions HOT 2
- v4 programming model - req.json is returning Body is unusable for post with JSON HOT 7
- Ensure v4 model compatibility with Static Web Apps HOT 1
- Add @azure/functions package to js sdk docs
- Add v4 model to trigger reference docs
- How do I reference parameters of output bindings in v4 HOT 3
- Make v4 entry point failures more obvious HOT 6
- Decide how v4 model should handle binding extension breaking changes HOT 6
- Is there any plan for when v4 will become ga HOT 1
- Add SQL trigger support to v4 model
- Queue message value corrupted
- [Azure functions v4.0]: How to get the input from service bus trigger? HOT 2
- Request for: Node.js Version 20 support HOT 1
- Add WebPubSub bindings/trigger type support to v4 model HOT 2
- Phantom functions appear when starting the v4 TypeScript app HOT 2
- Support streams (http) HOT 12
- v4 allow registering separate http methods to the same route HOT 1
- Support streams (azure resources) HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from azure-functions-nodejs-library.