anchor.diff:  <div class="space"></div>
   ++++
   
  -Note that altough we only return the `:user/id` from the mutation, the resolvers can walk the graph
  +Note that although we only return the `:user/id` from the mutation, the resolvers can walk the graph
   and fetch the other requested attributes.
   
   ==== Mutation join globals
  
positive.code: 
  As you can see, `Connect` will fire an error in case your query asks for something and it's not possible to get there.
  
  === Multiple inputs #TODO
  
  === Single input requirements
  
  At the moment we only know how to start a graph query from a "global" resolver.
  
  Another significant entry point for the graph are idents. Since an ident is really a lookup for a distinct entity, it is
  trivial to start a graph query at one. Examples are things like "product by id" and "user by email". It turns out that
  single-input resolvers automatically define how to start a graph query at an ident!
  
  For example we have a resolver to get the brand from the product id: so `:product/id` can be used to find that.
  Also the `:product/brand-id` can be realized from `:product/brand`. Thus, the following ident-join queries already work
  without having to define anything else:
  
  ```clojure
  (parser {} [{[:product/id 1] [:product/brand]}])
  
negative.code: 
  === Generating queries #TODO
  
  == Async parsing [[AsyncParsing]]
  
  If you want to write parsers to run in Javascript environments, then async operations are the norm. The async
  parser is a version of the parser were you can return core async channels from the readers. This allows
  for creation of parsers that do network requests or any other async operation. The async parser is still a *serial*
  parser, and it will have the same flow characteristics of the regular parser, so the order or resolution is
  preserved.
  
  To write an async parser we use the `p/async-parser` function. Here is an example:
  