Fn project is missing http operations (CRUD)

Question

I have spent my afternoon getting very excited about the container-native serverless platform 'fn project' - http://fnproject.io/.

I love the idea of the FaaS model but have no intention of locking myself into a particular cloud vendor for most of the lifetime of an app - and several other reasons including the desire to spin up the entire app on a small server anywhere if I choose.

fn project seems great for my needs until I finish perusing the documentation and all the relevant blog posts and suddenly think 'what? Wait....what??? Where are the http operations?'.

I cannot find a single reference anywhere that states if it is even possible to to have http triggers for different http operations (ie POST, PUT, PATCH, DELETE), let alone how I would do it.

I want to build REST api's (or certainly at the very least json-serving http-based RPC apis - if it doesn't have hypermedia links it isn't REST ;) but let's not get into that one in this thread)

Am I missing something here (certainly the correct bit of documentation)??

Can anybody please enlighten me as to how I would do this, or even tell me if I have totally misunderstood what I should use this for?

My excitement has gone soft for now but I'm hoping someone that will change with the right information.

It feels odd that I can't find anyone else complaining about this, so I think that indicates my misunderstanding perhaps.

Other solutions such as OpenFaaS look interesting but I dont wan't to have to learn how to deploy kubernetes and docker swarms if I can avoid it :)

Answer 1

I'm not an expert, but as of now it seems not possible to specify the http method inside the trigger. Check latest trigger spec : as you can see, there is no notion of http method here.

However, handling different HTTP methods can be done inside the function itself.

For example, in Java (with fdk-java v1.0.80), you can use com.fnproject.fn.api.httpgateway.HTTPGatewayContext as the first parameter of the function, as described in the section "Accessing HTTP Information From Functions" of the documentation :

In Fn for Java, when your function is being served by an HTTP trigger (or another compatible HTTP gateway) you can get access to both the incoming request headers for your function by adding a 'com.fnproject.fn.api.httpgateway.HTTPGatewayContext' parameter to your function's parameters.

Using this allows you to :

• ...
• Access the method and request URL for the trigger
• ...

You can then retrieve the HTTP method by calling getMethod() on the HTTPGatewayContext passed as parameter.

In other languages (with others fdk), it's possible to do the same :

• in Go : example calling RequestMethod() on context
• in Ruby : class HTTPContext
• in Python : class HTTPGatewayContext
• in Node : class HTTPGatewayContext

From this different contexts, you'll then be able to get method parameter passed when fn invoke --method=[GET|POST|...] (via fn-http-method header).

The main drawback here is that all HTTP methods should be handled in the same function. Nonetheless, you can structure your code to have only one class per method.

Answer 2

After some further thought it seems fairly clear now what my actual misunderstanding was....

When I have built Serverless framework services in the past (or built and deployed Lambda functions using terraform) I have been deploying to AWS and so have been using AWS's API Gateway offering (their product is actually called API gateway but its important to recognise that API Gateway is a distributed systems / micro-sevices design pattern).

API gateway makes it possible to route specific http request types including the method (GET,POST,PUT,DELETE) to the desired functions.

Platforms such as Fn project and OpenFaaS do not provide an out of the box api gateway solution and it seems we would need to take care of this ourselves.

These above mentioned platforms are about deployment of functions. We find the other bits via our product of choice.

Answer 3

The concept of fn project is to create functions with input/output independent of lower level protocols; we would be able to bind the function to several protocols on different systems.

In practice however only http is currently supported as far as I know.

You can always break the abstractions by reaching into the lower levels of the API (see norbdj answer) and finding HTTP related stuff. But is not present in higher level API because it was meant too be independent of it.