@vercel/fun
v1.1.1
Published
Local Lambda development environment
Downloads
2,253,628
Keywords
Readme
ƒun
Local serverless function λ development runtime.
Example
Given a Lambda function like this one:
// example/index.js
exports.handler = function(event, context, callback) {
callback(null, { hello: 'world' });
};
You can invoke this function locally using the code below:
import { createFunction } from '@vercel/fun';
async function main() {
// Starts up the necessary server to be able to invoke the function
const fn = await createFunction({
Code: {
// `ZipFile` works, or an already unzipped directory may be specified
Directory: __dirname + '/example'
},
Handler: 'index.handler',
Runtime: 'nodejs8.10',
Environment: {
Variables: {
HELLO: 'world'
}
},
MemorySize: 512
});
// Invoke the function with a custom payload. A new instance of the function
// will be initialized if there is not an available one ready to process.
const res = await fn({ hello: 'world' });
console.log(res);
// Prints: { hello: 'world' }
// Once we are done with the function, destroy it so that the processes are
// cleaned up, and the API server is shut down (useful for hot-reloading).
await fn.destroy();
}
main().catch(console.error);
Caveats
ƒun provides an execution environment that closely resembles the real Lambda environment, with some key differences that are documented here:
- Lambdas processes are ran as your own user, not the
sbx_user1051
user. - Processes are not sandboxed nor chrooted, so do not rely on hard-coded
locations like
/var/task
,/var/runtime
,/opt
, etc. Instead, your function code should use the environment variables that represent these locations (namelyLAMBDA_TASK_ROOT
andLAMBDA_RUNTIME_DIR
). - Processes are frozen by sending the
SIGSTOP
signal to the lambda process, and unfrozen by sending theSIGCONT
signal, not using the cgroup freezer. - Lambdas that compile to native executables (i.e. Go) will need to be compiled for your operating system. So if you are on macOS, then the binary needs to be executable on macOS.
Runtimes
ƒun aims to support all runtimes that AWS Lambda provides. Currently implemented are:
nodejs
for Node.js Lambda functions using the systemnode
binarynodejs6.10
for Node.js Lambda functions using a downloaded Node v6.10.0 binarynodejs8.10
for Node.js Lambda functions using a downloaded Node v8.10.0 binarynodejs10.x
for Node.js Lambda functions using a downloaded Node v10.15.3 binarynodejs12.x
for Node.js Lambda functions using a downloaded Node v12.22.7 binarynodejs14.x
for Node.js Lambda functions using a downloaded Node v14.18.1 binarypython
for Python Lambda functions using the systempython
binarypython2.7
for Python Lambda functions using a downloaded Python v2.7.12 binarypython3
for Python Lambda functions using the systempython3
binarypython3.6
for Python Lambda functions using a downloaded Python v3.6.8 binarypython3.7
for Python Lambda functions using a downloaded Python v3.7.2 binarygo1.x
for Lambda functions written in Go - binary must be compiled for your platformprovided
for custom runtimes