mirror of https://github.com/fnproject/fn.git synced 2022-10-28 21:29:17 +03:00

Files

Reed Allman 2341456334 FN_ prefix env vars

this adds `FN_` in front of env vars that we are injecting into calls, for
namespacing reasons. this will break code relying on the current variables but
if we want to do this, the chance is now really. alternatively, we could
maintain both the old and new for a short period of time to ease the
adjustment (speak now...). updated the docs, as well.

this also adds tests for the notoriously finicky configuration of the env vars
and headers when setting up a call. this won't test the container / request
for the call is actually receiving them, but it's a decent start and will yell
loudly enough upon formatting breakage.

added back FXLB_WAIT to a couple places so the lb can ride again

one thing for feedback:

headers are a bit confusing at the moment (not from this change, but that
behavior is kept here for now), we've a chance to fix them. currently, headers
in the request __are not__ prefixed with `FN_HEADER_`, i.e. 'hot'+sync containers
will receive `Content-Length` in the http request headers, yet a 'cold'
container from the same request would receive `FN_HEADER_Content-Length` in
its environment. This is additionally confusing because if this function were
hot+async, it would receive `FN_HEADER_Content-Length` in the headers, where
just changing it to sync goes back to `Content-Length`. If that was confusing,
then point made ;)

I propose to remove the `FN_HEADER_` prefix for request headers in the
environment, so that the request headers and env will match, as request
headers already are of this format (not prefixed). please lmk thoughts here

Would be fine with going back to the 'plain' vars too, then this patch will
mostly just be adding tests and changing `FN_FORMAT` to `FORMAT`. obviously,
from the examples, it's a bit ingrained now. anyway, entirely up to y'all.

2017-09-06 07:24:50 -07:00

3.4 KiB

Raw Blame History

Writing Functions

This will give you the basic overview of writing base level functions. You can also use higher level abstractions that make it easier such as lambda.

Also, for complete examples in various languages, see the examples directory. We have language libraries for Go, Javascript and Ruby.

Code

The most basic code layout in any language is as follows, this is pseudo code and is not meant to run.

# Read and parse from STDIN
body = JSON.parse(STDIN)

# Do something
return_struct = doSomething(body)

# If sync, respond:
STDOUT.write(JSON.generate(return_struct))
# If async, update something:
db.update(return_struct)

Inputs

Inputs are provided through standard input and environment variables. We'll just talk about the default input format here, but you can find others here. To read in the function body, just read from STDIN.

You will also have access to a set of environment variables.

FN_REQUEST_URL - the full URL for the request (parsing example)
FN_APP_NAME - the name of the application that matched this route, eg: myapp
FN_ROUTE - the matched route, eg: /hello
FN_METHOD - the HTTP method for the request, eg: GET or POST
FN_CALL_ID - a unique ID for each function execution.
FN_FORMAT - a string representing one of the function formats, currently either default or http. Default is default.
FN_MEMORY - a number representing the amount of memory available to the call, in MB
FN_HEADER_$X - the HTTP headers that were set for this request. Replace $X with the upper cased name of the header and replace dashes in the header with underscores.
- $X - any configuration values you've set for the Application or the Route. Replace X with the upper cased name of the config variable you set. Ex: minio_secret=secret will be exposed via MINIO_SECRET env var.

Warning: these may change before release.

Logging

Standard out is where you should write response data for synchronous functions. Standard error is where you should write for logging, as it was intended.

So to write output to logs, simply log to STDERR. Here are some examples in a few languages.

In Go, simply use the log package, it writes to STDERR by default.

log.Println("hi")

In Node.js:

console.error("hi");

More details for Node.js here.

In Ruby:

STDERR.puts("hi")

Using Lambda Functions

Lambda everywhere

Lambda support for Oracle Functios enables you to take your AWS Lambda functions and run them anywhere. You should be able to take your code and run them without any changes.

Creating Lambda functions is not much different than using regular functions, just use the lambda-node runtime.

fn init --runtime lambda-node --name lambda-node

Be sure the filename for your main handler is func.js.

TODO: Make Java and Python use the new workflow too.

Next Steps

Packaging your function

3.4 KiB Raw Blame History