Originally posted on The Quilt Project:
This is a written (expanded) narrative of the content from a talk I first gave at PhillyETE on April 23rd, 2014. It mostly follows the flow of the presentation given then, but with a level of detail that I hope enhances clarity of the ideas therein. The talk’s original slides are available, though the key illustrations and bullet points contained therein are replicated (and somewhat enhanced) below. When audio/video of the talk is published, I will update this page to link to it. Discussion about this piece has taken place on Hacker News, reddit, and Lobsters.
I have two claims of which I would like to convince you today:
View original 7,490 more words
Lots of programming problems can be modeled by pipe-lining data through series of sequential or parallel processing steps. This data flow allows us to separate computational tasks into meaningful modules and
get more focused code base that is easier to debug and reason about. For example, a pipeline with three steps that takes input ‘req’ and successfully process it, would look like this:
And if at any stage there is error during the processing, we would skip the rest and return error…
Now, there are many ways to implement error handling, but this can easily end up in a messy combination of conditional statements and/or throwing and catching exceptions to stop processing. This adds noise to the real code logic and makes composing tasks harder… I’ve recently started to use Either monad to help with this this problem and am very happy about the results:
Here, I’m using Either implementation from the nice functional library Falktale…
Till next time…
So, nice… ;)
— Srdjan (@djidja8) August 26, 2014
So, I’ll be putting out some examples – simple and to the point… Hopefully ;)
With that in mind, compare this ‘todo’ application implementation done with Hamlet to your favorite framework:
When composing your server apps with OWIN there are many options. OWIN spec is very flexible and it doesn’t force you into particular application architecture (this is a good thing). So, using standard OWIN middleware components to compose your application is pretty easy and straightforward.
I prefer to clearly (at the assembly level) separate middleware from the server and the application. That makes it easier to work with for a bigger team, and when potentially, application teams are not the same as server and/or middleware team. Organizing your application in this way could look something like this, starting with middleware components project:
and then application is configured and ran like this:
So, having this in place, application developers – potentially different team(s) then middleware team – would write:
which models application interface as resources, and exposes them via standard HTTP verbs…
If you prefer CQRS – you can have middleware dispatch to handlers and then write your applications something like this:
Bottom line, OWIN is awesome.