Sapper only processes small request and response (with small request body, returning small response body) now;
Three level granularity (global, module, function handler) middleware controller and unified middleware presentation;
Typesafe abstraction, keep the same spirit with hyper;
For easy using, will supply some convenient macros to help write business logic;
Global object cross requests;
Philosophy
Sapper's philosophy is plugined, typed, hierarchical control.
Plugined
Sapper's core contains only middleware/plugin system, router system, request and response definitions, and some other basic facilities. Nearly all practical features, such as query parameter, body parameter, cookie, session, json, xml, orm..., are supplied by the outer plugins.
Sapper's plugin is very easy to write. One rust module realized a function on the prototype of
fn (&mutRequest) ->Result<()>;// before pluginfn (&Request,&mutResponse) ->Result<()>;// after plugin
can be thought as Sapper's plugin. Sample template please refer sapper_query_params plugin.
Typed
In Sapper, nearly every important thing is a Type. They are:
Each module is a type, different modules are different types;
Every plugin supply 0~n types for handler getting values;
Inherited from hyper's typed spirit, all headers, mime and so on should use types for manipulation.
Hierarchical Control
Sapper forces you to put router in each module (in main.rs, you can not write it, no space left for you to write);
Sapper forces you to seperate the router binding and the handler realization;
Sapper's plugin processor can be used in app level wrapper, module level wrapper, and each handler. These three level hierarchical controls make it flexible to construct your business.