A Runtime-agnostic API for serverless HTTP request processing

[trieloff]

Overview

If we wanted to deploy our serverless functions to more than one runtime environment, what would a good API look like?

I've been looking at APIs for

• Openwhisk
• AWS Lambda (same as Netlify)
• Azure Functions
• Fastly Compute@Edge
• Cloudflare Workers
• Deno
• Express (same as Google Cloud)

Details

export async function(request:Request, context:Set<String,*>): Response {
  return new Response("Not implemented yet", {
    status: 501
  })
}

Design Notes

• Request: from fetch API
• Response: from fetch API
• async: better than Lambda's callbacks
• return: better than a callback on request, context or setting a property on context
• export: always use the default export
• context: read-only container for:
  • default parameters
  • environment information

Proposed Actions

• build adapters for openwhisk
• refactor our actions
• build adapters for other runtimes, e.g. Azure Functions

[tripodsan]

I assume that all actions are nodejs based... so why using the Request/Response from Fetch API and not based NodeJS's ClientRequest/Response and/or using express like handlers? eg:

async function handleDefault(req, res) {
  // access environment (aka action params)
  req.local.env.get(....);

  res.status(501).send('not implmented yet');
}

export function(app) {
  app.use(handleDefault);
}

this would also allow to add different routes, for the more complex actions, eg:

async function handleHealthCheck(req, res) {
  ...
}

export function(app) {
  app.get('/_status_check/healthcheck.json', handleHealthCheck)
  app.use(handleDefault);
}

[tripodsan]

return: better than a callback on request, context or setting a property on context

using a Response return value is kind of weird, as it is inherently tied to the http request. Also, the Response from the Fetch API is kind of consumer type, so it is also weird for user code to create one.

---

if the API should be based on http request processing, I would not use fetch semantics, since they are built for clients.
if the API should be independent of http (like openwhisk tries to do), we should invent our own abstraction or reuse openwhisk.

[trieloff]

I assume that all actions are nodejs based... so why using the Request/Response from Fetch API

I'm assuming JS, but not node so that we keep the door open for more lightweight runtimes like deno or Cloudflare Workers. 99% of our I/O is via HTTPS, so we have little need for the full power of node.

[trieloff]

or using express like handlers?

I see that multi-action functions are creeping monoliths and do not want to encourage that (I'm fine with not being able to prevent them either). Furthermore I do not like that express mixes request and environment and that it uses function parameters (input) as vehicles for results (output). A clear return value seems to be much cleaner.

[trieloff]

Also, the Response from the Fetch API is kind of consumer type, so it is also weird for user code to create one.

I acknowledge that, but the fetch API is well known and vendor independent, so that it is easy to pick up for developers. In fact that API is used by Cloudflare Workers and Fastly, in both cases you'd use the constructor.

[tripodsan]

I see that multi-action functions are creeping monoliths and do not want to encourage that (I'm fine with not being able to prevent them either).

I disagree (of course). if you're implementing an API (e.g a backend for a SPA) it's much more convenient to have all code in 1 action that to have 100 actions loosely kept together by an API controller and a lot of release engineering glue.

Furthermore I do not like that express mixes request and environment and that it uses function parameters (input) as vehicles for results (output). A clear return value seems to be much cleaner.

maybe, but that's a necessity for the direct binding to the server request/response. which might indeed be a bit weird for the serverless usecase.

I acknowledge that, but the fetch API is well known and vendor independent, so that it is easy to pick up for developers.

but most of the developers are used to express which also has a wide adoption base, examples and documentation. It just doesn't feel right to use client side API.

In fact that API is used by Cloudflare Workers and Fastly, in both cases you'd use the constructor.

ok.

---

one side note: using the express API, there already are implementations for:

• openwhisk https://github.com/adobe/openwhisk-action-utils#module_expressify
• aws lambda https://www.serverless.com/plugins/serverless-express
• Google Cloud Platform - Cloud functions https://www.serverless.com/plugins/serverless-express
• Microsoft Azure - Cloud functions https://www.serverless.com/plugins/serverless-express

[tripodsan]

but I think I agree with your proposal. using the Fetch API is standard and more modern :-)

what about creating a poc for one of your actions, eg git-resolve-ref (since you already started)?

another interresting question is how to be agostic about the service catalog. e.g content-proxy invokes word2md, which might (or not?) be invoked in the same environment. So something like a ServiceResolver (similar to version lock :-) is probably needed.

[stefan-guggisberg]

+1 for Fetch-like Request/Response objects. It can't be 100% compliant with the Fetch Spec though. The Fetch Spec was written for the browser use-case and includes many features/restrictions targeted at the browser (CORS etc) which don't make sense in the server-side use-case. It should be a pragmatic adaption of the spec, similar to node-fetch, helix-fetch et al.

[stefan-guggisberg]

BTW: Fastly's as-fetch is experimental at best and doesn't adhere to the Fetch spec. resp.status() instead of resp.status, const content = resp.text() instead of const content = await resp.text() etc.

[trieloff]

AS does not have await or promises, so the second would be an example of a pragmatic adaptation.

[trieloff]

WIP: https://github.com/trieloff/universal-serverless

[tripodsan]

I suggest to create a library that:

• provides Request and Response
• provides a mechanism to invoke other actions/functions/lambdas/scripts...
• provides the adapter entry points for the clouds (this could be separated into N libraries later)
• add logging to the context
• instruments epsagon
• add status reporting

[trieloff]

now here: https://github.com/adobe/helix-deploy