(00:20) Jon asks Pete to explain what Superscribe’s graph-based routing means. Pete explains how traditional routing needs to check each route for a match, one at a time. Graph-based routing stores using a structure, so there are some performance gains due to only matching routes with a matching structure rather than using string matching.
Extensibility due to strongly typed route nodes
(02:37) Each node in the graph is a strongly typed entity, so you can use an activation function for each node in the graph to determine if it’s a match rather than just using a simple regex match. You can write custom activation functions for any node. For parameter matching, Superscribe uses TryParse rather than regex matches.
(04:22) There are three guiding principles behind Superscribe: composability, efficiency and extensibility.
The OWIN connection
(05:22) Jon asks where Superscribe can be used. Pete says it’s currently usable in Web API and OWIN, with NancyFx and possibly MVC on the way.
(06:02) In addition to activation functions, you can also define an action function which says what should happen when a node is matched. This allows running different OWIN middleware based on route matches. This means you can hook up authentication middleware using an action function which will only operate on a specific node.
Graphs vs. Trees
(08:16) You can hook up optional nodes, which would allow things like an optional /debug/ route prefix which would hook up tracing middleware. Pete says this is something that wouldn’t be possible with tree-based routing (available in NancyFx).
(09:00) Jon asks what the difference is between tree-based routing and graph-based routing. Both are connected nodes, and trees are a type of graph in which the node connections branch out and ever reconnect, whereas in a graph any node may connect to any other node.
API options: Different ways to define route graphs
(09:53) Jon asks how developers will define nodes in Superscribe. Pete talks about the difference between economy and expressivity: economic design has fewer options but is easy to learn, while expressive design offers many options but a steeper learning curve. Superscribe is currently more expressive, using a domain specific language using operator overloads. It overloads the / symbol to add segments and the | operator to allow defining multiple routes (or the entire graph) in a single line.
(12:28) Jon says that you can always add an economic API layer over an expressive one. Pete agrees and says that since everything’s strongly typed underneath, you can configure it explicitly or fluently as well (if you don’t like the DSL).
(13:14) Jon asks about how to hook in action functions or activator functions. Pete says they’re currently not available in the DSL, so you’d need to build those notes out by hand at this point.
Miscellaneous questions and pretend ending
(15:08) Jon asks about using routes for localization. Pete talks about some options for doing that.
(16:28) Jon asks what’s next on the list. Pete lists some features: syntax improvements and OWIN middleware ideas.
(19:12) Jon asks how people can learn more and keep up, Pete talks about Superscribe.org.
Update on the 0.4 release (follow-up phone call)
(22:11) Jon asks what’s new in the 0.4 release. Pete starts by describing some improvements to the routing syntax.
(23:02) You can now combine Web API replacement routing, traditional routing, Attribute Routing and Superscribe in the same application, so you can pick and choose.
(23:24) You can wire it up with an IOC container, so you can compose different components based on routes. You can also use route information in OWIN middleware.
(23:56) Everything about the new release is up on the Superscribe.org site.