Links

Think of me as a web crawler with taste.

Cap'n Proto: RPC Protocol

Cap’n Proto RPC:

Cap’n Proto RPC employs TIME TRAVEL! The results of an RPC call are returned to the client instantly, before the server even receives the initial request!

There is, of course, a catch: The results can only be used as part of a new request sent to the same server. If you want to use the results for anything else, you must wait.

However, Cap’n Proto promises support an additional feature: pipelining. The promise actually has methods corresponding to whatever methods the final result would have, except that these methods may only be used for the purpose of calling back to the server. Moreover, a pipelined promise can be used in the parameters to another call without waiting.

An interesting feature which limits the number of network hops in the query is a pipeline of dependent requests.

∙ Software Engineering

Using Pseudo-URIs Between Services

Phil Calçado:

In my experience, a good-enough specification for a pURI should specify:

  • How many segments are there and if teams and service owners can add new segments
  • What is the encoding and escaping expected for the text
  • What in the identifier should be treated as opaque data as opposed to parts where consumers can make assumptions about data formats

We’ve been playing with almost the exact same scheme recently for some of our services.

∙ Software Engineering

Tackling Complexity in CQRS

Vladik Khononov:

From my point of view, the CQRS-induced complexity is largely accidental, and thus can be avoided. To illustrate my point, I want to discuss the goal of CQRS, and then analyze 3 common sources of accidental complexity in CQRS-based systems.

I find myself nodding to the sentiments of this post. It feels like doggedly pursing a theoretical ideal can lead to unnecessary difficulty in CQRS implementations.

∙ Software Engineering