Provide a `Response` class for HTTP trigger functions about azure-functions-nodejs-library HOT 3 CLOSED

Discussed during standup today. We will add a Response class, but we will not provide res as a parameter

from azure-functions-nodejs-library.

My feeling is that a res object is more important in frameworks that rely on callbacks, where you frequently get a bunch of references to objects (err, req, res, etc.) passed as arguments. By contrast, I think a goal of the async/await pattern is to make inputs & outputs more intuitive and IMO res is clearly an output. We could mix & match qualities of both, but that gets confusing fast. For example, if I modify the body on the res argument, but return a different object from the promise, which takes priority?

What if we provide a Response class, but don't pass res as an argument? Aka your second example code would look like this:

app.get('route', (_, req) => {
  const res = new Response({ body: { foo: 'bar' } });
  if (req.headers.has('accepts')) {
    const accepts = req.headers.get('accepts');
    if (accepts.indexOf('application/json')) {
      res.headers.add('content-type', 'application/json');
    }
  }
  return res;
});

I've been modeling after undici a lot and they do have both ResponseInit (a barebones/flexible object) and Response (a more opinionated/helpful class), so this would be consistent. Of course users would be free to use this new class or just create their own.

from azure-functions-nodejs-library.

As I think about it more, I do think that the "res-as-param" design might be better addressed at a higher-level wrapper over the library, as that's the sort of thing that might be better tied to a framework like Express/Fastify/etc. and not really core to Functions.

Accepting the Response object as the return value from a Function might be a good idea, as it's clear that this is pretty low level, so using the raw types might be beneficial there. Would also save on having to write type definitions!

from azure-functions-nodejs-library.