Introduction

Snap Extensions is a library which makes it easy to create reusable plugins
that extend your Snap application with modular chunks of functionality such
as session management, user authentication, templating, or database
connection pooling.

We achieve this by requiring that you create a datatype that holds an
environment for your application and wrap it around the Snap monad. This new
construct becomes your application's handler monad and gives you access to
your application state throughout your handlers.

Warning: this interface is still EXPERIMENTAL and has a very high likelihood
of changing substantially in coming versions of Snap.

Using Snap Extensions

Every extension has an interface and at least one implementation of that
interface.

For some extensions, like Heist, there is only ever going to be one
implementation of the interface. In these cases, both the interface and the
implementation are exported from the same module, Snap.Extension.Heist.Impl.

Hypothetically, for something like session management though, there could be
multiple implementations, one using a HDBC backend, one using a MongoDB
backend and one just using an encrypted cookie as backend. In these cases,
the interface is exported from Snap.Extension.Session, and the
implementations live in Snap.Extension.Session.HDBC,
Snap.Extension.Session.MongoDB and Snap.Extension.Session.CookieStore.

Keeping this in mind, there are a number of things you need to do to use
Snap extensions in your application. Let's walk through how to set up a
simple application with the Heist extension turned on.

Define Application State and Monad

First, we define a record type AppState for holding our application's state,
including the state needed by the extensions we're using.

At the same time, we also define the monad for our application, App, as
a type alias to SnapExtend AppState. SnapExtend is a MonadSnap and
a MonadReader, whose environment is a given type; in our case, AppState.

An important thing to note is that the -State types that we use in the
fields of AppState are specific to each implementation of a extension's
interface. That is, Snap.Extension.Session.HDBC will export a different
SessionState to Snap.Extension.Session.CookieStore, whose internal
representation might be completely different.

This state is what the extension's implementation needs to be able to do its
job.

Provide Instances For "HasState" Classes

Now we have a datatype that contains all the internal state needed by our
application and the extensions it uses. That's a great start! But when do we
actually get to use this interface and all the functionality that these
extensions export? What is actually being extended?

We use the interface provided by an extension inside our application's
monad, App. Snap extensions extend our App with new functionality by
allowing us to user their exported functions inside of our handlers. For
example, the Heist extension provides the function:

Is App a MonadHeist? Well, not quite yet. Any MonadReader which is also
a MonadSnap whose environment contains a HeistState is a MonadHeist.
That sounds a lot like our App, doesn't it? We just have to tell the Heist
extension how to find the HeistState in our AppState:

Stated another way, if we give our AppState the ability to hold a HeistState
and let the HasHeistState typeclass know how to get/set this state, we are
automagically given the ability to render heist templates in our handlers.

With these instances, our application's monad App is now a MonadHeist
giving it access to operations like:

render :: MonadHeist m => ByteString -> m ()

and

heistLocal :: (TemplateState n -> TemplateState n) -> m a -> m a

Define The Initializer

So, our monad is now a MonadHeist, but how do we actually construct our
AppState and turn an App () into a Snap ()? We need to do this upfront,
once and right before our web server starts listening for connections.

Snap extensions have a thing called an Initializer that does these things.
Each implementation of a Snap extension interface provides an Initializer
for its -State type. We must construct an initializer type for our -State
type, AppState. An Initializer monad is provided in this library to make
it easy to do this. For your convenience, Initializer is an instance of
MonadIO.

In addition to constructing the AppState, the Initializer monad also
constructs the init, destroy and reload functions for our application from
the init, reload and destroy functions for the extensions.

Although it won't cause a compile-time error, it is important to get the
order of the initializers correct as much as possible, otherwise they may be
reloaded and destroyed in the wrong order. The right order is an order
where every extension's dependencies are initialised before that extension.
For example, Snap.Extension.Session.HDBC would depend on something which
would extend the monad with MonadConnectionPool, i.e.,
Snap.Extension.ConnectionPool. If you had this configuration it would be
important that you put the connectionPoolInitializer before the
sessionInitializer in your appInitializer.

This Initializer AppState can then be passed to runInitializer, which
combines our initializer action with our application's handler to produce a
Snap handler (which can be passed to httpServe), a cleanup action (which
you can run after httpServe finishes), and a reload action (which, for
example, you may want to use in your handler for the path "admin/reload".

MonadSnap m => IO [(ByteString, Maybe ByteString)] -> m () It takes the
reload action returned by runInitializer and returns a Snap action which
renders a simple page showing how the reload went. To avoid denial of
service attacks, the reload handler only works for requests made from the
local host.

Simplified Snap Extension Server

This is, of course, a lot of avoidable boilerplate. Snap extensions framework
comes with another module Snap.Extension.Server, which provides an
interface mimicking that of Snap.Http.Server. Their function names clash,
so if you need to use both of them in the same module, use a qualified
import. Using this module, the example above becomes:

All it needs is a Initializer AppState and an App () and it is ready to go.
You might be wondering what happened to all the reload handler bits we
had before: That stuff has been absorbed into the config for the server.

One quick note: quickHttpServe doesn't take a config, instead it uses the
defaults augmented with any options specified on the command-line. The
default reload handler path in this case is admin/reload.

This behaves exactly as the above example apart from the reload handler.

With this, we now have a fully functional base application that makes use of
the Snap Extensions mechanism.

To initialize a directory with all of this setup provided as a starting
point, simply cd into the desired location and type: snap init. An
example "Timer" extension will also be included for your convenience.

A SnapExtend is a MonadReader and a MonadSnap whose environment is
the application state for a given progam. You would usually type alias
SnapExtend AppState to something like App to form the monad in which
you write your application.

The Initializer monad. The code that initialises your application's
state is written in the Initializer monad. It's used for constructing
values which have cleanup/destroy and reload actions associated with them.

Returns a Snap handler, a cleanup action, and a reload action. The
list returned by the reload action is for error reporting. There is
one tuple in the list for each Snap extension; the first element of
the tuple is the name of the Snap extension, and the second is a Maybe
which contains Nothing if there was no error reloading that extension
and a Just with the ByteString containing the error message if there
was.

Given the Initializer for your application's state, and a value in the
monad formed by SnapExtend wrapped it, this returns a Snap action, a
cleanup action and a reload action.

Although it has the same type signature, this is not the same as return
in the Initializer monad. Return simply lifts a value into the
Initializer monad, but this lifts the value and its destroy/reload
actions. Use this when making your own Initializer actions.

This takes the last value of the tuple returned by runInitializer,
which is a list representing the results of an attempt to reload the
application's Snap Extensions, and turns it into a Snap action which
displays the these results.