Familiarizing myself with a new codebase using Ruby’s TracePoint and Graphviz

Christian Joudrey
2 min readJul 10, 2017

About a year ago I found myself wanting to learn more about the internals of Ruby’s GraphQL gem. When I first opened the lib/graphql folder I was a bit intimidated. I found 30 files and over 10 folders containing even more files.

I figured a good starting point would be to investigate GraphQL::Schema.execute as that’s the entry-point my application was using to execute GraphQL queries against my schema.

Once I started digging into the source of GraphQL::Schema, I felt like I was missing something. I wanted some sort of map to quickly give me an idea of how each piece of the library interacted together.

That’s when I discovered Ruby’s TracePoint class. With TracePoint you can have a proc get called every time a method is called and every time a method returns.

By tracing all method calls made to classes in the GraphQL namespace I would have the data needed to build a call graph which would give me an overview of how the gem executes my queries.

Next I needed a tool to draw this graph, that’s when I discovered Graphviz (a graph visualization software). What I liked about the tool is the simple file format used to define a graph.

Code in DOT format on the left to generate graph on the right

Using both tools I was able to trace GraphQL::Schema.execute. The graph was pretty big at first, but by limiting the depth I generated a more concise one.

If I ever wanted to dig deeper into a specific method, say GraphQL::Query.valid? I could do so by using that as my starting point for tracing.

If you’re interested in generating your own call graphs, I’ve open sourced the code used to generate the graphs above: cjoudrey/code_mapper.

Here’s a sample usage for the above graph:

--

--

Christian Joudrey

Production Engineering @Shopify. Rock climber and amateur piano player. Previously working on GraphQL @GitHub.