« Back to Index

[GPN: Ganners Pipe Notation]

View original Gist on GitHub

Tags: #GPN #design #architecture #systems

GPN: Ganners Pipe Notation.md

GPN: Ganners Pipe Notation

Designed by Mark Gannaway @BuzzFeed

It’s a way of articulating the design of a system, using unix pipes (and other recognised syntax), without worrying about the concrete implementation.

For example:

request_drink
| open_bottle
| acknowledge_satisfying_cork_sound
| pour_generously --tolerance=1
| tee
  | >(drink)
  | >(drink)
  | >(drink...)
| hangover_recovery_sequence

But more seriously…

taxi_dispatcher -f 
    | update_robot_position --id=1
    | nearby_stations --limit=1 --max-distance=.35km
    | google_maps_traffic_report

Which breaks down to:

• taxi_dispatcher:
  Outputs latitude/longitude with a robot id

• update_robot_position:
  Listens for latitude/longitude and moves a robot

• nearby_stations:
  Listens for latitude/longitude and finds nearby stations

• google_traffic_report:
  Listens for latitude/longitude and checks traffic

Naming things

In the following example we’re defining the requirements for rendering HTML components.

shared_components=curl $API/data.json?lang=$lang
    | tee
        >(render_metadata --brand=bf)
        >(render_navbar --lang=$lang --brand=bf)
        >(jq .subcomponents | render_subcomponents --brand=bf)
        >(render_subcomponents_js --brand=bf)
        >(render_subcomponents_css --brand=bf)

Note: tee is a simple command which provides us the primitives to fork a stream concurrently.

We’ve given it a name (shared_components) in order for us to be able to utilise it in a larger pipeline, like so:

http_request | shared_components | render_template

No behavioural abstractions

We want to avoid complicating these definitions, so instead of trying to have something like render_template(foo) and render_template(bar), we should instead use two separate calls:

http_request | shared_components | render_foo_template
http_request | shared_components | render_bar_template

Complexity reduced to simpler concepts

http_request
  | in_cache || shared_components
  | render_foobar_template
  | convert_to_amp
  | minify_html
  | validate_html
  | inline_css --file-pattern=*critical*
  | inline_images --file-pattern=*static-assets*
  | gzip

What details do we lose?

• Fault tolerance and application errors (although possible using stderror redirection).
• Considerations of the CAP theorem (e.g. defining shared infrastructure).
• Performance considerations (with respect to network latency).
• Logical forking (though this can be expressed with added detail).

Conclusion

the symbols enable us to further simplify, optimize, and describe a system.