anchor.diff:   :data {:id 1}}
   ----
   
  -The `:type` and `:dest` keys are mandatory to be present in the frame.
  +NOTE: The `:type` and `:dest` keys are mandatory to be present in the frame.
  +
  +The messages are by default serialized using transit+json serialization format
  +but the system is open to be extended with other formats. The serialization is
  +completelly transparent to the user, the catacumba will do all the hard work for
  +you.
   
   Knowing the frame structure, the best way to define a postal handler is using
   multimethods, because they allow easy dispatch by value:
  
positive.code: 
  (defmethod myhandler [:subscribe :timeupdate]
    [context frame]
    (pc/stream context
               (fn [context out]
                 (a/go-loop []
                   (when-let [_ (a/>! out (pc/response :message {:time (now)}))]
                     (a/<! (a/timeout 100))
                     (recur))))))
  ----
  
  The `catacumba.handlers.postal/stream` function is analgous to the
  `catacumba.core/sse` with the difference that it encodes the messages properly
  using *postal* protocol.
  
  
  [NOTE]
  ====
  This documention will explain only the backend related stuff. For client usage,
  please refer to the link:https://github.com/funcool/postal[client documentation].
  ====
  
  [NOTE]
  ====
  Take care that this not analogous to websockets emulation on top of http. Is
  just a message protocol that allows take aside the REST api and build your own
  one based on your own messages and your own semantics.
  
  It can be considered a low-level layer for build graphql like endpoints.
  ====
  
  
  
negative.code: 
  === Postal
  
  The tipical web application usually follows the api REST architecture, but the main
  problem of that is that is bound directly to the HTTP semantics that are not
  always coherent or not always clear how to use.
  
  This is a backend side implementation
  link:https://funcool.github.io/catacumba/latest/postal.html[postal protocol],
  that allows expose rich apis based on the user needs on top of http/websockets.
  
  The general idea behind the protocol and this library is borrowed from
  link:https://facebook.github.io/relay/[Facebook Relay] and
  link:http://netflix.github.io/falcor/[Netflix's Falcor].
  The main differents with them is that this library only represents the transport and
  message routing layer layer, so it's is nonobstructive and not copupled with
  concrete framework and persistence.
  
  One of the great examples where this library fits in a perfection is a
  transport and message routing layer for
  link:https://github.com/omcljs/om/wiki/Quick-Start-(om.next)[Om.Next].
  
  
  ==== Getting Started
  
  The *postal* handler looks like a default _catacumba_ handler with one extra
  argument: frame. The frame is a structurd message received from the client that
  has this aspect:
  
  [source, clojure]
  ----
  