calls, apps, and routes listing were previously returning the entire data set, which just won't scale. this adds pagination with cursoring forward to each of these endpoints (see the [docs](docs/definitions.md)). the patch is really mostly tests, shouldn't be that bad to pick through. some blarble about implementation is in order: calls are sorted by ids but allow searching within certain `created_at` ranges (finally). this is because sorting by `created_at` isn't feasible when combined with paging, as `created_at` is not guaranteed to be unique -- id's are (eliding theoreticals). i.e. on a page boundary, if there are 200 calls with the same `created_at`, providing a `cursor` of that `created_at` will skip over the remaining N calls with that `created_at`. also using id will be better on the index anyway (well, less of them). yay having sortable ids! I can't discern any issues doing this, as even if 200 calls have the same created_at, they will have different ids, and the sort should allow paginating them just fine. ids are also url safe, so the id works as the cursor value just fine. apps and routes are sorted by alphabetical order. as they aren't guaranteed to be url safe, we are base64'ing them in the front end to a url safe format and then returning them, and then base64 decoding them when we get them. this does mean that they can be relatively large if the path/app is long, but if we don't want to add ids then they were going to be pretty big anyway. a bonus that this kind of obscures them. if somebody has better idea on formatting, by all means. notably, we are not using the sql paging facilities, and we are baking our own based on cursors, which ends up being much more efficient for querying longer lists of resources. this also should be easy to implement in other non-sql dbs and the cursoring formats we can change on the fly since we are just exposing them as opaque strings. the front end deals with the base64 / formatting, etc and the back end is taking raw values (strfmt.DateTime or the id for calls). the cursor that is being passed to/by the user is simply the last resource on the previous page, so in theory we don't even need to return it, but it does make it a little easier to use, also, cursor being blank on the last page depends on page full-ness, so sometimes users will get a cursor when there are no results on next page (1/N chance, and it's not really end of world -- actually searching for the next thing would make things more complex). there are ample tests for this behavior. I've turned off all query parameters allowing `LIKE` queries on certain listing endpoints, as we should not expose sql behavior through our API in the event that we end up not using a sql db down the road. I think we should only allow prefix matching, which sql can support as well as other types of databases relatively cheaply, but this is not hooked up here as it didn't 'just work' when I was fiddling with it (can add later, they're unnecessary and weren't wired in before in front end). * remove route listing across apps (unused) * fix panic when doing `/app//`. this is prob possible for other types of endpoints, out of scope here. added a guard in front of all endpoints for this * adds `from_time` and `to_time` query parameters to calls, so you can e.g. list the last hour of tasks. these are not required and default to oldest/newest. * hooked back up the datastore tests to the sql db, only run with sqlite atm, but these are useful, added a lot to them too. * added a bunch of tests to the front end, so pretty sure this all works now. * added to swagger, we'll need to re-gen. also wrote some words about pagination workings, I'm not sure how best to link to these, feedback welcome. * not sure how we want to manage indexes, but we may need to add some (looking at created_at, mostly) * `?route` changed to `?path` in routes listing, to keep consistency with everything else * don't 404 when searching for calls where the route doesn't exist, just return an empty list (it's a query param ffs) closes #141
Fn 
Fn is an event-driven, open source, functions-as-a-service compute platform that you can run anywhere. Some of it's key features:
- Write once
- Run anywhere
- Public, private and hybrid cloud
- Import functions directly from Lambda and run them wherever you want
- Easy to use for developers
- Easy to manage for operators
- Written in Go
- Simple yet powerful extensibility
Prequisites
- Docker 17.05 or later installed and running
- Logged into Docker Hub (
docker login)
Quickstart
Install CLI tool
This isn't required, but it sure makes things a lot easier. Just run the following to install:
curl -LSs https://raw.githubusercontent.com/fnproject/cli/master/install | sh
This will download a shell script and execute it. If the script asks for a password, that is because it invokes sudo.
Run Fn Server
Then fire up an Fn server:
fn start
This will start Fn in single server mode, using an embedded database and message queue. You can find all the configuration options here. If you are on Windows, check here.
Your First Function
Functions are small but powerful blocks of code that generally do one simple thing. Forget about monoliths when using functions, just focus on the task that you want the function to perform.
First, create an empty directory called hello and cd into it.
The following is a simple Go program that outputs a string to STDOUT. Copy and paste the code below into a file called func.go.
package main
import (
"fmt"
)
func main() {
fmt.Println("Hello from Fn!")
}
Now run the following CLI commands:
# Initialize your function
# This detects your runtime from the code above and creates a func.yaml
fn init
# Set your Docker Hub username
export FN_REGISTRY=<DOCKERHUB_USERNAME>
# Test your function
# This will run inside a container exactly how it will on the server
fn run
# Deploy your functions to the Fn server (default localhost:8080)
# This will create a route to your function as well
fn deploy --app myapp
Now you can call your function:
curl http://localhost:8080/r/myapp/hello
# or:
fn call myapp /hello
Or in a browser: http://localhost:8080/r/myapp/hello
That's it! You just deployed your first function and called it. To update your function
you can update your code and run fn deploy myapp again.
To Learn More
- Visit our Functions Tutorial Series
- See our full documentation
- View all of our examples
- You can also write your functions in AWS Lambda format
Get Involved
- Join our Slack Community
- Learn how to contribute
- See milestones for detailed issues
User Interface
This is the graphical user interface for Fn. It is currently not buildable.
docker run --rm -it --link functions:api -p 4000:4000 -e "API_URL=http://api:8080" treeder/functions-ui
For more information, see: https://github.com/treeder/functions-ui
Next up
Check out the Tutorial Series
It will demonstrate some of Fn capabilities through a series of exmaples. We'll try to show examples in most major languages. This is a great place to start!