Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/wintercg/proposal-functions-api

Discussing standardizing serverless JS functions
https://github.com/wintercg/proposal-functions-api

Last synced: 3 months ago
JSON representation

Discussing standardizing serverless JS functions

Host: GitHub
URL: https://github.com/wintercg/proposal-functions-api
Owner: wintercg
License: apache-2.0
Created: 2023-02-10T19:39:31.000Z (almost 2 years ago)
Default Branch: main
Last Pushed: 2023-07-06T14:13:14.000Z (over 1 year ago)
Last Synced: 2024-06-30T06:46:35.863Z (5 months ago)
Size: 6.84 KB
Stars: 21
Watchers: 15
Forks: 1
Open Issues: 2
Metadata Files:
- Readme: README.md
- License: LICENSE

Awesome Lists containing this project

README

        # JavaScript Serverless Functions Standardization

## Problem

Today every competing JavaScript functions API is different enough that we end up with lower developer productivity and vendor lock-in. Lower developer productivity because developers have to learn multiple ways to write the JavaScript function code and may have to write more complex code to avoid vendor lock-in. Organizations wanting to leverage multiple functions providers or move from one provider to another incur significant additional cost.

## Goal

Goal is to define a JavaScript functions API that avoids vendor lock-in and facilitates developer productivity while being general enough to allow different implementations and optimizations behind the scenes.

Things we should try to standardize

* function sig (including parameters and what’s available on them)

  * how functions get events(CloudEvents)?

* key supporting apis like

  * log method signature

  * exporting the function

  * how to report an error

Things we should not try to standardize

* JS framework for invoking the functions

  * http framework that is used(Fastify, Express, etc…)

* underlying buildpack/image that ends up running

* accessing platform specific APIs offered by the vendor platforms(ex: google apis)

* output format/how you view logs

* how you monitor functions

## Scenarios

Scenario 1: Writing a HelloWorld function in one vendors platform and moving to other vendors platforms

Shouldn’t have to change the code

Build steps and or configuration may have to change

Scenario 2: Writing in one vendor and moving to another (ex using Google Cloud Functions and move to Cloudflare workers)

If code does not use vendor specific APIs you should not have to change the code.

If code uses vendor specific APIs, you may need to change the code if you also need to use a different vendor for those calls.

Build steps and or configuration may have to change

## Implementations

* [AWS Lambda](./docs/implementations/aws.md)

* [Cloudflare Workers](./docs/implementations/cloudflare.md)

* [Lagon](./docs/implementations/lagon.md)

* [Netlify Edge Functions](./docs/implementations/netlify.md)

* [Openshift Serverless Functions](./docs/implementations/openshift-serverless-functions.md)

* [Vercel Edge Functions](./docs/implementations/vercel.md)

## Contributors

* https://github.com/Ethan-Arrowood

* https://github.com/jasnell

* https://github.com/styfle

* https://github.com/QuiiBz

* https://github.com/ascorbic

* https://github.com/lholmquist

* https://github.com/kentonv

* https://github.com/mhdawson