logo

Full Stack Time Travel Debugging

We share a demo of a prototype we’ve developed for debugging an application’s full stack.
profile photo
Brian Hackett
Understanding a distributed application is hard.  Breaking the application down into services and spreading them across a network will increase its overall complexity, but the biggest difficulty is inspecting the application’s behavior.  It’s fairly easy to debug something happening on your own machine.  It’s harder to debug a service running on a remote machine, and even harder to debug a group of remote and interconnected services.  The main tools available for this are logging and telemetry, which only go so far.
We want to make it easy to understand and debug complex distributed applications, and believe the best way to do that is to see the application as a whole, rather than looking at its pieces in isolation (there’s even a parable for this).  Instead of a debugger for each individual service, we need a single debugger for the full stack.
At Replay we’ve built a time travel debugger that makes it easy to look at pieces of a web application in isolation – the frontend and individual Node.js backend services.  It’s actually pretty straightforward to go from this to a full stack time travel debugger.  We can separately record each service, and stitch those recordings together by matching up the network calls one service makes with the handlers on the other side.  Debugging the combined recordings lets anyone follow requests as they flow between services, identify the root causes of problems, find new opportunities for optimizations, and so on.
We’ve built a prototype full stack debugger.  The video below shows this prototype and how to use it to get a complete understanding of a request for some data: we follow the request from where it is triggered by a frontend React component into the backend handler, the database the backend queries, and the filtering performed before returning to the frontend for displaying.  Replay’s print statements (like logging, except they update immediately and retroactively) are especially helpful for understanding how data flows between the services.
This prototype is just a starting point.  We want to hear your experiences working on full stack applications and the parts that are annoying or difficult, so we can make it as easy as possible to build these complex systems.  If you have any feedback, or want to hear updates as this project evolves and try it out when it’s ready, reach us at hi@replay.io or fill out this contact form and we’ll be in touch.
Related posts
post image
In this post we develop the ideas underlying Replay’s upcoming Performance Analysis, using a real world regression drawn from the development of our devtools.
post image
What exactly is time travel? How do we ensure we can reliably record and deterministically replay any website?
Powered by Notaku