lanes
The lanes project offers a modestly general LFE HTTP routing library for multiple BEAM-based HTTP servers / web frameworks.
The lanes library is used to create "framework modules" which use it to implement support for the targetted framework/HTTP library. The following frameworks are at the top of our list:
- Elli
- Barista
- Erlang (inets) (partially implemented)
- YAWS (partially implemented)
- Nova (not started)
- Cowboy (not started)
Elli
Writing Elli applications in LFE with lanes is very similar as in Erlang:
the only difference is that you don't create a handle/3
function. Instead,
you use defroutes
which creates handle/3
under the covers for you.
Everything else is vanilla Elli. To be clear, one still needs to provide the
handle/2
and handle_event/3
functions in the module where defroutes
is
called.
Example
See the lanes Elli example.
Barista
Barista is a thin wrapper around the
Erlang standard library's httpd, written in LFE. The lanes-barista
module supports a defroutes
macro that generates a handle/3
function
and allows barista web applications to dispatch based upon request method and path.
Example
See the lanes Barista example.
Erlang (inets)
TBD
Example
See the lanes Erlang inets example.
YAWS
WARNING: YAWS support is old and needs to be re-visited to make sure everything still works ...
The YAWS lanes
plugin creates a routes/3
function which can then
be called in the out/1
function that is required of a
YAWS appmod module.
For an example of this in action, see
this mini REST-api.
A few important things to note here:
- Each route is composed of an HTTP verb, a path, and a function to execute should both the verb and path match.
- The function call in the route has access to the
arg-data
passed from YAWS; this contains all the data you could conceivably need to process a request. (You may need to import theyaws_api.hrl
in your module to parse the data of your choice, though.) - If a path has a segment preceded by a colon, this will be converted to a
variable by the
(defroutes ...)
macro; the variable will then be accessible from the function you provide in that route. - The
(defroutes ...)
macro generates theroutes/3
function; it's three arguments are the HTTP verb (method name), the path info (a list of path segments, with the":varname"
segments converted tovarname
/ variable segments), and then thearg-data
variable from YAWS.
More details:
lanes needs to provide YAWS with an out/1
function. The location of this
function is configured in your etc/yaws.conf
file in the
<appmods ...>
directives (it can be repeated for supporting multiple
endpoints).
YAWS will call this function with one argument: the YAWS arg
record
data. Since this function is the entry point for applications running under
YAWS, it is responsible for determining how to process all requests.
The out/1
function in lane+YAWS-based apps calls the routes/3
function
generated by the (defroutes ...)
lanes/YAWS mamcro.
When a lanes-based project is compiled, the routes/3
function is available for use via
whatever modules have defined routes with defroutes
.
Nova
TBD
Cowboy
TBD