Files
fn-serverless/examples/blog
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
..
2017-07-26 10:50:19 -07:00
2016-11-06 09:25:12 -08:00
2017-09-06 07:24:50 -07:00
2016-11-01 13:15:27 -07:00
2017-05-18 18:59:34 +00:00
2017-05-18 18:59:34 +00:00
2017-05-18 18:59:34 +00:00
2017-09-06 07:24:50 -07:00
2016-11-01 13:15:27 -07:00
2017-05-15 11:00:15 -07:00
2017-09-06 07:24:50 -07:00
2016-08-30 16:47:34 -03:00

Blog API Example

A simple serverless blog API

Requirements

  • Remote MongoDB instance (for example heroku)
  • Running Oracle Functions API

Development

Building image locally

# SET BELOW TO YOUR DOCKER HUB USERNAME
USERNAME=YOUR_DOCKER_HUB_USERNAME

# build it
docker run --rm -v "$PWD":/go/src/github.com/fnproject/hello -w /go/src/github.com/fnproject/hello funcy/go:dev go build -o function
docker build -t $USERNAME/func-blog .

Publishing to DockerHub

# tagging
docker run --rm -v "$PWD":/app treeder/bump patch
docker tag $USERNAME/func-blog:latest $USERNAME/func-blog:`cat VERSION`

# pushing to docker hub
docker push $USERNAME/func-blog

Running it on Oracle Functions

First you need a running Oracle Functions API

First, let's define this environment variables

# Set your Function server address
# Eg. 127.0.0.1:8080
FUNCAPI=YOUR_FUNCTIONS_ADDRESS

# Set your mongoDB server address
# Eg. 127.0.0.1:27017/blog
MONGODB=YOUR_MONGODB_ADDRESS

Testing image

./test.sh

Running with Oracle Functions

With this command we are going to create an application with name blog and also defining the app configuration DB.

curl -X POST --data '{
    "app": {
        "name": "blog",
        "config": { "DB": "'$MONGODB'" }
    }
}' http://$FUNCAPI/v1/apps

Now, we can create our blog routes:

  • /posts - to create (authenticated) and list posts
  • /posts/:id - to read post
  • /token - to get a JWT
curl -X POST --data '{
    "route": {
        "image": "'$USERNAME'/func-blog",
        "path": "/posts"
    }
}' http://$FUNCAPI/v1/apps/blog/routes
curl -X POST --data '{
    "route": {
        "image": "'$USERNAME'/func-blog",
        "path": "/posts/:id"
    }
}' http://$FUNCAPI/v1/apps/blog/routes
curl -X POST --data '{
    "route": {
        "image": "'$USERNAME'/func-blog",
        "path": "/token"
    }
}' http://$FUNCAPI/v1/apps/blog/routes

Testing function

Now that we created our Oracle Functions route, let's test our routes

curl -X POST http://$FUNCAPI/r/blog/posts

This command should return {"error":"Invalid authentication"} because we aren't sending any token.

Authentication

Creating a blog user

First let's create our blog user. In this example an user test with password test.

docker run --rm -e DB=$MONGODB -e NEWUSER='{ "username": "test", "password": "test" }' $USERNAME/functions-blog
Getting authorization token

Now, to get authorized to post in our Blog API endpoints we must request a new token with a valid user.

curl -X POST --data '{ "username": "test", "password": "test" }' http://$FUNCAPI/r/blog/token

This will output a token like this:

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOiIyMDE2LTA5LTAxVDAwOjQzOjMxLjQwNjY5NTIxNy0wMzowMCIsInVzZXIiOiJ0ZXN0In0.aPKdH3QPauutFsFbSdQyF6q1hqTAas_BCbSYi5mFiSU"}

Let's save that token in the environment

BLOG_TOKEN=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOiIyMDE2LTA5LTAxVDAwOjQzOjMxLjQwNjY5NTIxNy0wMzowMCIsInVzZXIiOiJ0ZXN0In0.aPKdH3QPauutFsFbSdQyF6q1hqTAas_BCbSYi5mFiSU
Posting in your blog

curl -X POST --header "Authorization: Bearer $BLOG_TOKEN" --data '{ "title": "My New Post", "body": "Hello world!", "user": "test" }' http://$FUNCAPI/r/blog/posts